[PATCH v2] kretprobe: avoid re-registration of the same kretprobe earlier

[PATCH v2] kretprobe: avoid re-registration of the same kretprobe earlier

[Wang ShaoBo]

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 <bobo.shaobowang@huawei.com>
Signed-off-by: Cheng Jian <cj.chengjian@huawei.com>
---
 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;
 
+	/* 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 = kprobe_addr(&rp->kp);
 		if (IS_ERR(addr))
-- 
2.25.1

Re: [PATCH v2] kretprobe: avoid re-registration of the same kretprobe earlier

[Steven Rostedt]

Masami,

Care to review?

Thanks!

-- Steve


On Thu, 28 Jan 2021 20:44:27 +0800
Wang ShaoBo <bobo.shaobowang@huawei.com> wrote:

> 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 <bobo.shaobowang@huawei.com>
> Signed-off-by: Cheng Jian <cj.chengjian@huawei.com>
> ---
>  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;
>  
> +	/* 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 = kprobe_addr(&rp->kp);
>  		if (IS_ERR(addr))

Re: [PATCH v2] kretprobe: avoid re-registration of the same kretprobe earlier

[Steven Rostedt]

On Fri, 29 Jan 2021 15:23:47 +0530
"Naveen N. Rao" <naveen.n.rao@linux.vnet.ibm.com> wrote:

> diff --git a/kernel/kprobes.c b/kernel/kprobes.c
> index f7fb5d135930fa..63a36f33565354 100644
> --- a/kernel/kprobes.c
> +++ b/kernel/kprobes.c
> @@ -1530,6 +1530,7 @@ static inline int check_kprobe_rereg(struct kprobe *p)
>                 ret = -EINVAL;
>         mutex_unlock(&kprobe_mutex);
> 
> +       WARN_ON(ret);
>         return ret;
>  }

Please use WARN_ON_ONCE(ret);

Thanks,

-- Steve

Re: [PATCH v2] kretprobe: avoid re-registration of the same kretprobe earlier

[Steven Rostedt]

On Fri, 29 Jan 2021 22:29:47 +0900
Masami Hiramatsu <mhiramat@kernel.org> wrote:

> I'll send a patch over this to replace those check with WARN_ON() since
> it's a software bug and should be fixed.

Please use WARN_ON_ONCE()

Thanks!

-- Steve