Re: [PATCH] kprobes: avoid crash when rmmod/insmod modules after ftrace_disabled

[Masami Hiramatsu (Google) <mhiramat@kernel.org>]

Hi,

Thanks for reporting!


On Tue, 25 Nov 2025 10:05:36 +0800
Ye Bin <yebin@huaweicloud.com> wrote:

> From: Ye Bin <yebin10@huawei.com>
> 
> There's a issue as follows when rmmod modules after ftrace disabled:

You may see something like;

Failed to unregister kprobe-ftrace (error -19)

or

Failed to disarm kprobe-ftrace at <function name> (error -19)

right before this BUG, don't you?
If you reported with that line, it's more easier to understand.


> BUG: unable to handle page fault for address: fffffbfff805000d
> PGD 817fcc067 P4D 817fcc067 PUD 817fc8067 PMD 101555067 PTE 0
> Oops: Oops: 0000 [#1] SMP KASAN PTI
> CPU: 4 UID: 0 PID: 2012 Comm: rmmod Tainted: G        W  OE
> Tainted: [W]=WARN, [O]=OOT_MODULE, [E]=UNSIGNED_MODULE
> RIP: 0010:kprobes_module_callback+0x89/0x790
> RSP: 0018:ffff88812e157d30 EFLAGS: 00010a02
> RAX: 1ffffffff805000d RBX: dffffc0000000000 RCX: ffffffff86a8de90
> RDX: ffffed1025c2af9b RSI: 0000000000000008 RDI: ffffffffc0280068
> RBP: 0000000000000000 R08: 0000000000000001 R09: ffffed1025c2af9a
> R10: ffff88812e157cd7 R11: 205d323130325420 R12: 0000000000000002
> R13: ffffffffc0290488 R14: 0000000000000002 R15: ffffffffc0280040
> FS:  00007fbc450dd740(0000) GS:ffff888420331000(0000) knlGS:0000000000000000
> CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: fffffbfff805000d CR3: 000000010f624000 CR4: 00000000000006f0
> Call Trace:
>  <TASK>
>  notifier_call_chain+0xc6/0x280
>  blocking_notifier_call_chain+0x60/0x90
>  __do_sys_delete_module.constprop.0+0x32a/0x4e0
>  do_syscall_64+0x5d/0xfa0
>  entry_SYSCALL_64_after_hwframe+0x76/0x7e
> 
> The above issue occurs because the kprobe was not removed from the hash
> list after ftrace_disable.
> To prevent the system from restarting unexpectedly after ftrace_disable,
> in such cases, unregister_kprobe() ensures that the probe is removed from
> the hash list, preventing subsequent access to already freed memory.
> 
> Fixes: 6f0f1dd71953 ("kprobes: Cleanup disabling and unregistering path")
> Signed-off-by: Ye Bin <yebin10@huawei.com>
> ---
>  kernel/kprobes.c | 26 ++++++++++++++++++++++++--
>  1 file changed, 24 insertions(+), 2 deletions(-)
> 
> diff --git a/kernel/kprobes.c b/kernel/kprobes.c
> index ab8f9fc1f0d1..d735a608b810 100644
> --- a/kernel/kprobes.c
> +++ b/kernel/kprobes.c
> @@ -1731,8 +1731,30 @@ static int __unregister_kprobe_top(struct kprobe *p)
>  
>  	/* Disable kprobe. This will disarm it if needed. */
>  	ap = __disable_kprobe(p);
> -	if (IS_ERR(ap))
> -		return PTR_ERR(ap);
> +	if (IS_ERR(ap)) {
> +		int ret = PTR_ERR(ap);
> +
> +		/*
> +		 * If ftrace disabled we need to delete kprobe node from
> +		 * hlist or aggregation list. If nodes are not removed when
> +		 * modules are removed, the already released nodes will
> +		 * remain in the linked list. Subsequent access to the
> +		 * linked list may then trigger exceptions.
> +		 */
> +		if (ret != -ENODEV)
> +			return ret;
> +
> +		ap = __get_valid_kprobe(p);
> +		if (!ap)
> +			return ret;
> +
> +		if (ap == p)
> +			hlist_del_rcu(&ap->hlist);
> +		else
> +			list_del_rcu(&p->list);

Instead of repeating this process, we should ignore
-ENODEV error from ftrace directly. BTW, ftrace_disabled is set
when ftrace_kill() is called, that means ftrace is no more usable.
So I think we can just ignore ftrace operation in
__disarm_kprobe_ftrace().

Thank you,


> +
> +		return ret;
> +	}
>  
>  	WARN_ON(ap != p && !kprobe_aggrprobe(ap));
>  
> -- 
> 2.34.1
> 


-- 
Masami Hiramatsu (Google) <mhiramat@kernel.org>