linux-kernel - Re: [RFC PATCH] kprobes: Fix suspicious RCU usage WARN in get

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-Id: <20191221035814.cb1800611c09b02bc448308d@kernel.org>
Date:   Sat, 21 Dec 2019 03:58:14 +0900
From:   Masami Hiramatsu <mhiramat@...nel.org>
To:     John Garry <john.garry@...wei.com>
Cc:     <naveen.n.rao@...ux.ibm.com>, <anil.s.keshavamurthy@...el.com>,
        <davem@...emloft.net>, <linux-kernel@...r.kernel.org>,
        <paulmck@...nel.org>, <anders.roxell@...aro.org>
Subject: Re: [RFC PATCH] kprobes: Fix suspicious RCU usage WARN in
 get_kprobe()

Hi John,

Thanks for your work. Actually, I already sent the same fix 2 weeks ago.

https://lore.kernel.org/lkml/157535316659.16485.11817291759382261088.stgit@devnote2/

Thank you,

On Fri, 20 Dec 2019 20:49:51 +0800
John Garry <john.garry@...wei.com> wrote:

> With CONFIG_PROVE_RCU_LIST set, we may get the following WARN in the
> test code:
> 
> Kprobe smoke test: started
> 
> =============================
> WARNING: suspicious RCU usage
> 5.5.0-rc1-00013-ge15bd404ed10-dirty #802 Not tainted
> -----------------------------
> kernel/kprobes.c:329 RCU-list traversed in non-reader section!!
> 
> other info that might help us debug this:
> 
> rcu_scheduler_active = 2, debug_locks = 1
> 1 lock held by swapper/0/1:
> #0: ffff800011bf3648 (kprobe_mutex){+.+.}, at: register_kprobe+0x94/0x5a0
> 
> stack backtrace:
> CPU: 1 PID: 1 Comm: swapper/0 Not tainted 5.5.0-rc1-00013-ge15bd404ed10-dirty #802
> Hardware name: Huawei Taishan 2280 /D05, BIOS Hisilicon D05 IT21 Nemo 2.0 RC0 04/18/2018
> Call trace:
> dump_backtrace+0x0/0x1a0
> show_stack+0x14/0x20
> dump_stack+0xe8/0x150
> lockdep_rcu_suspicious+0xcc/0x110
> get_kprobe+0xb8/0xc0
> __get_valid_kprobe+0x18/0xc8
> register_kprobe+0x9c/0x5a0
> init_test_probes+0x80/0x400
> init_kprobes+0x13c/0x154
> do_one_initcall+0x88/0x428
> kernel_init_freeable+0x21c/0x2c4
> kernel_init+0x10/0x108
> ret_from_fork+0x10/0x18
> Kprobe smoke test: passed successfully
> 
> The code comment tells us the locking requirements:
> 
> /*
>  * This routine is called either:
>  * 	- under the kprobe_mutex - during kprobe_[un]register()
>  * 				OR
>  * 	- with preemption disabled - from arch/xxx/kernel/kprobes.c
>  */
> struct kprobe *get_kprobe(void *addr)
> {
> 	struct hlist_head *head;
> 	struct kprobe *p;
> 
> 	head = &kprobe_table[hash_ptr(addr, KPROBE_HASH_BITS)];
> 	hlist_for_each_entry_rcu(p, head, hlist,
> 
> And we have the kprobe_mutex held in the path of concern, so add a
> RCU list traversal check condition for this.
> 
> Signed-off-by: John Garry <john.garry@...wei.com>
> ---
> I sent as an RFC as I am not 100% certain that this is the right fix.
> It does solve my WARN.
> 
> I also assume __get_valid_kprobe() will require a similar change for
> similar reason.
> 
> diff --git a/kernel/kprobes.c b/kernel/kprobes.c
> index 53534aa258a6..908abdac77f1 100644
> --- a/kernel/kprobes.c
> +++ b/kernel/kprobes.c
> @@ -326,7 +326,8 @@ struct kprobe *get_kprobe(void *addr)
>  	struct kprobe *p;
>  
>  	head = &kprobe_table[hash_ptr(addr, KPROBE_HASH_BITS)];
> -	hlist_for_each_entry_rcu(p, head, hlist) {
> +	hlist_for_each_entry_rcu(p, head, hlist,
> +				 mutex_is_locked(&kprobe_mutex)) {
>  		if (p->addr == addr)
>  			return p;
>  	}
> -- 
> 2.17.1
> 


-- 
Masami Hiramatsu <mhiramat@...nel.org>