From nobody Mon Dec 15 03:22:08 2025 Delivered-To: importer2@patchew.org Received-SPF: pass (zohomail.com: domain of vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; envelope-from=linux-kernel-owner@vger.kernel.org; helo=vger.kernel.org; Authentication-Results: mx.zohomail.com; spf=pass (zohomail.com: domain of vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org ARC-Seal: i=1; a=rsa-sha256; t=1611837832; cv=none; d=zohomail.com; s=zohoarc; b=hUTSera3u4p/N/Dv3I9H0YcnSoNWNcEysgu0WrzPLr5/TQcbkELAzCtla1P15/asEuyfgoeQpiPo0zNYbtv/hZm88gBnm3jY1sjJUm/aFdz+DtmA3PQIY6FLvdBe3Pc7J1R/KikQkBt+EsYgkekwGmFglOUNmm+RDTO/Wl5FBDo= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1611837832; h=Content-Type:Content-Transfer-Encoding:Cc:Date:From:List-Id:MIME-Version:Message-ID:Subject:To; bh=m5dG+icMGPbkpoy4CwRuvBuMz5++uogMHt3pKT3+9co=; b=VvqQu3JG1K7EFwetQGgNZwsny6Meyf2KpCC2t5kbREqKBLC95PFC5GZoEKRd8JZiRK/jl3/S1+v6yFqd/73M8pNp/GeMxh8LjI4Jbp5pYe3501HTe0qJUJMioPU8V//s1qrhiBfy0/AUlgDdKvJWnQXl5+BYClTKWEmgMKiVX2c= ARC-Authentication-Results: i=1; mx.zohomail.com; spf=pass (zohomail.com: domain of vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mx.zohomail.com with SMTP id 1611837832413340.9618823956655; Thu, 28 Jan 2021 04:43:52 -0800 (PST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231364AbhA1MnQ (ORCPT ); Thu, 28 Jan 2021 07:43:16 -0500 Received: from szxga04-in.huawei.com ([45.249.212.190]:11614 "EHLO szxga04-in.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229616AbhA1MnO (ORCPT ); Thu, 28 Jan 2021 07:43:14 -0500 Received: from DGGEMS414-HUB.china.huawei.com (unknown [172.30.72.60]) by szxga04-in.huawei.com (SkyGuard) with ESMTP id 4DRKpK2bSCz160Fl; Thu, 28 Jan 2021 20:41:13 +0800 (CST) Received: from huawei.com (10.175.103.91) by DGGEMS414-HUB.china.huawei.com (10.3.19.214) with Microsoft SMTP Server id 14.3.498.0; Thu, 28 Jan 2021 20:42:16 +0800 From: Wang ShaoBo CC: , , , , , , , , Subject: [PATCH v2] kretprobe: avoid re-registration of the same kretprobe earlier Date: Thu, 28 Jan 2021 20:44:27 +0800 Message-ID: <20210128124427.2031088-1-bobo.shaobowang@huawei.com> X-Mailer: git-send-email 2.25.1 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [10.175.103.91] X-CFilter-Loop: Reflected To: unlisted-recipients:; (no To-header on input) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" Our system encountered a re-init error when re-registering same kretprobe, where the kretprobe_instance in rp->free_instances is illegally accessed after re-init. Implementation to avoid re-registration has been introduced for kprobe before, but lags for register_kretprobe(). We must check if kprobe has been re-registered before re-initializing kretprobe, otherwise it will destroy the data struct of kretprobe registered, which can lead to memory leak, system crash, also some unexpected behaviors. We use check_kprobe_rereg() to check if kprobe has been re-registered before running register_kretprobe()'s body, for giving a warning message and terminate registration process. Signed-off-by: Wang ShaoBo Signed-off-by: Cheng Jian --- kernel/kprobes.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/kernel/kprobes.c b/kernel/kprobes.c index f7fb5d135930..5c4a884953e9 100644 --- a/kernel/kprobes.c +++ b/kernel/kprobes.c @@ -1978,6 +1978,10 @@ int register_kretprobe(struct kretprobe *rp) if (!kprobe_on_func_entry(rp->kp.addr, rp->kp.symbol_name, rp->kp.offset)) return -EINVAL; =20 + /* If only rp->kp.addr is specified, check reregistering kprobes */ + if (rp->kp.addr && check_kprobe_rereg(&rp->kp)) + return -EINVAL; + if (kretprobe_blacklist_size) { addr =3D kprobe_addr(&rp->kp); if (IS_ERR(addr)) --=20 2.25.1