BUG: using smp_processor_id() in preemptible code in radix_tree_node_alloc

91 views
Skip to first unread message

syzbot

unread,
Jun 4, 2020, 10:02:19ā€ÆPM6/4/20
to bjorn.a...@linaro.org, da...@davemloft.net, ku...@kernel.org, linux-...@vger.kernel.org, manivannan...@linaro.org, net...@vger.kernel.org, syzkall...@googlegroups.com
Hello,

syzbot found the following crash on:

HEAD commit: acf25aa6 Merge tag 'Smack-for-5.8' of git://github.com/csc..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=13d6307a100000
kernel config: https://syzkaller.appspot.com/x/.config?x=5263d9b5bce03c67
dashboard link: https://syzkaller.appspot.com/bug?extid=3eec59e770685e3dc879
compiler: gcc (GCC) 9.0.0 20181231 (experimental)
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=15bd4c1e100000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1520c9de100000

IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+3eec59...@syzkaller.appspotmail.com

RAX: ffffffffffffffda RBX: 00007ffdf01d56d0 RCX: 00000000004406c9
RDX: 0000000000000000 RSI: 0000000020000240 RDI: 0000000000000003
RBP: 0000000000000005 R08: 0000000000000001 R09: 0000000000000031
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000401f50
R13: 0000000000401fe0 R14: 0000000000000000 R15: 0000000000000000
BUG: using smp_processor_id() in preemptible [00000000] code: syz-executor036/6796
caller is radix_tree_node_alloc.constprop.0+0x200/0x330 lib/radix-tree.c:262
CPU: 0 PID: 6796 Comm: syz-executor036 Not tainted 5.7.0-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x188/0x20d lib/dump_stack.c:118
check_preemption_disabled lib/smp_processor_id.c:47 [inline]
debug_smp_processor_id.cold+0x88/0x9b lib/smp_processor_id.c:57
radix_tree_node_alloc.constprop.0+0x200/0x330 lib/radix-tree.c:262
radix_tree_extend+0x256/0x4e0 lib/radix-tree.c:424
idr_get_free+0x60c/0x8e0 lib/radix-tree.c:1492
idr_alloc_u32+0x170/0x2d0 lib/idr.c:46
idr_alloc+0xc2/0x130 lib/idr.c:87
qrtr_port_assign net/qrtr/qrtr.c:703 [inline]
__qrtr_bind.isra.0+0x12e/0x5c0 net/qrtr/qrtr.c:756
qrtr_autobind net/qrtr/qrtr.c:787 [inline]
qrtr_autobind+0xaf/0xf0 net/qrtr/qrtr.c:775
qrtr_sendmsg+0x1d6/0x770 net/qrtr/qrtr.c:895
sock_sendmsg_nosec net/socket.c:652 [inline]
sock_sendmsg+0xcf/0x120 net/socket.c:672
____sys_sendmsg+0x6e6/0x810 net/socket.c:2352
___sys_sendmsg+0x100/0x170 net/socket.c:2406
__sys_sendmsg+0xe5/0x1b0 net/socket.c:2439
do_syscall_64+0xf6/0x7d0 arch/x86/entry/common.c:295
entry_SYSCALL_64_after_hwframe+0x49/0xb3
RIP: 0033:0x4406c9
Code: 25 02 00 85 c0 b8 00 00 00 00 48 0f 44 c3 5b c3 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 fb 13 fc ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:00007ffdf01d56c8 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
RAX: ffffffffffffffda RBX: 00007ffdf01d56d0 RCX: 00000000004406c9
RDX: 0000000000000000 RSI: 0000000020000240 RDI: 0000000000000003
RBP: 0000000000000005 R08: 0000000000000001 R09: 0000000000000031
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000401f50
R13: 0000000000401fe0 R14: 0000000000000000 R15: 0000000000000000


---
This bug is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzk...@googlegroups.com.

syzbot will keep track of this bug report. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
syzbot can test patches for this bug, for details see:
https://goo.gl/tpsmEJ#testing-patches

Eric Biggers

unread,
Jun 4, 2020, 11:55:59ā€ÆPM6/4/20
to Matthew Wilcox, syzbot, bjorn.a...@linaro.org, da...@davemloft.net, ku...@kernel.org, linux-...@vger.kernel.org, manivannan...@linaro.org, net...@vger.kernel.org, syzkall...@googlegroups.com
[+Cc Matthew Wilcox]

Possibly a bug in lib/radix-tree.c? this_cpu_ptr() in radix_tree_node_alloc()
can be reached without a prior preempt_disable(). Or is the caller of
idr_alloc() doing something wrong?

syzbot

unread,
Jun 5, 2020, 2:09:05ā€ÆAM6/5/20
to bjorn.a...@linaro.org, da...@davemloft.net, ebig...@kernel.org, ku...@kernel.org, linux-...@vger.kernel.org, manivannan...@linaro.org, net...@vger.kernel.org, syzkall...@googlegroups.com, wi...@infradead.org
syzbot has bisected this bug to:

commit e42671084361302141a09284fde9bbc14fdd16bf
Author: Manivannan Sadhasivam <manivannan...@linaro.org>
Date: Thu May 7 12:53:06 2020 +0000

net: qrtr: Do not depend on ARCH_QCOM

bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=17e22212100000
start commit: acf25aa6 Merge tag 'Smack-for-5.8' of git://github.com/csc..
git tree: upstream
final crash: https://syzkaller.appspot.com/x/report.txt?x=14122212100000
console output: https://syzkaller.appspot.com/x/log.txt?x=10122212100000
Reported-by: syzbot+3eec59...@syzkaller.appspotmail.com
Fixes: e42671084361 ("net: qrtr: Do not depend on ARCH_QCOM")

For information about bisection process see: https://goo.gl/tpsmEJ#bisection

Matthew Wilcox

unread,
Jun 5, 2020, 7:29:26ā€ÆAM6/5/20
to Eric Biggers, syzbot, bjorn.a...@linaro.org, da...@davemloft.net, ku...@kernel.org, linux-...@vger.kernel.org, manivannan...@linaro.org, net...@vger.kernel.org, syzkall...@googlegroups.com
On Thu, Jun 04, 2020 at 08:55:55PM -0700, Eric Biggers wrote:
> Possibly a bug in lib/radix-tree.c? this_cpu_ptr() in radix_tree_node_alloc()
> can be reached without a prior preempt_disable(). Or is the caller of
> idr_alloc() doing something wrong?

Yes, the idr_alloc() call is plainly wrong:

mutex_lock(&qrtr_port_lock);
if (!*port) {
rc = idr_alloc(&qrtr_ports, ipc,
QRTR_MIN_EPH_SOCKET, QRTR_MAX_EPH_SOCKET + 1,
GFP_ATOMIC);

If we can take a mutex lock, there's no excuse to be using GFP_ATOMIC.
That (and the call slightly lower in the function) should be GFP_KERNEL
as the minimal fix (below). I'll send a followup patch which converts
this IDR to the XArray instead.

diff --git a/net/qrtr/qrtr.c b/net/qrtr/qrtr.c
index 2d8d6131bc5f..d2547711d20c 100644
--- a/net/qrtr/qrtr.c
+++ b/net/qrtr/qrtr.c
@@ -692,15 +692,15 @@ static int qrtr_port_assign(struct qrtr_sock *ipc, int *port)
if (!*port) {
rc = idr_alloc(&qrtr_ports, ipc,
QRTR_MIN_EPH_SOCKET, QRTR_MAX_EPH_SOCKET + 1,
- GFP_ATOMIC);
+ GFP_KERNEL);
if (rc >= 0)
*port = rc;
} else if (*port < QRTR_MIN_EPH_SOCKET && !capable(CAP_NET_ADMIN)) {
rc = -EACCES;
} else if (*port == QRTR_PORT_CTRL) {
- rc = idr_alloc(&qrtr_ports, ipc, 0, 1, GFP_ATOMIC);
+ rc = idr_alloc(&qrtr_ports, ipc, 0, 1, GFP_KERNEL);
} else {
- rc = idr_alloc(&qrtr_ports, ipc, *port, *port + 1, GFP_ATOMIC);
+ rc = idr_alloc(&qrtr_ports, ipc, *port, *port + 1, GFP_KERNEL);
if (rc >= 0)
*port = rc;

Eric Biggers

unread,
Jun 5, 2020, 12:11:24ā€ÆPM6/5/20
to Matthew Wilcox, syzbot, bjorn.a...@linaro.org, da...@davemloft.net, ku...@kernel.org, linux-...@vger.kernel.org, manivannan...@linaro.org, net...@vger.kernel.org, syzkall...@googlegroups.com
On Fri, Jun 05, 2020 at 04:29:22AM -0700, Matthew Wilcox wrote:
> On Thu, Jun 04, 2020 at 08:55:55PM -0700, Eric Biggers wrote:
> > Possibly a bug in lib/radix-tree.c? this_cpu_ptr() in radix_tree_node_alloc()
> > can be reached without a prior preempt_disable(). Or is the caller of
> > idr_alloc() doing something wrong?
>
> Yes, the idr_alloc() call is plainly wrong:
>
> mutex_lock(&qrtr_port_lock);
> if (!*port) {
> rc = idr_alloc(&qrtr_ports, ipc,
> QRTR_MIN_EPH_SOCKET, QRTR_MAX_EPH_SOCKET + 1,
> GFP_ATOMIC);
>
> If we can take a mutex lock, there's no excuse to be using GFP_ATOMIC.
> That (and the call slightly lower in the function) should be GFP_KERNEL
> as the minimal fix (below). I'll send a followup patch which converts
> this IDR to the XArray instead.

I did see that the GFP_ATOMIC was unnecessary, but it wasn't obvious to me that
it was actually *wrong*.

Shouldn't this requirement be documented for the @gfp argument to idr_alloc()?

- Eric

Cheng Du

unread,
Mar 14, 2021, 9:21:53ā€ÆPM3/14/21
to syzkaller-bugs
Following the discussion on this thread, I submitted the proposed patch to syzbot, and
it seemed to have stopped the crashing.

Just wondering if there is any side-effect if GFP_ATOMIC -> GFP_KERNEL, and there
are other places in the same qrtr.c that uses GFP_ATOMIC. Should we look into those
as well?

Regards,
Du Cheng

syzbot

unread,
Jun 7, 2021, 12:47:08ā€ÆPM6/7/21
to bjorn.a...@linaro.org, brooke...@gmail.com, core...@netfilter.org, da...@davemloft.net, dsa...@kernel.org, duch...@gmail.com, ebig...@kernel.org, f...@strlen.de, gre...@linuxfoundation.org, kad...@netfilter.org, ku...@kernel.org, linux-...@vger.kernel.org, manivannan...@linaro.org, net...@vger.kernel.org, netfilt...@vger.kernel.org, pa...@netfilter.org, sk...@linuxfoundation.org, syzkall...@googlegroups.com, wi...@infradead.org, yosh...@linux-ipv6.org
syzbot suspects this issue was fixed by commit:

commit 43016d02cf6e46edfc4696452251d34bba0c0435
Author: Florian Westphal <f...@strlen.de>
Date: Mon May 3 11:51:15 2021 +0000

netfilter: arptables: use pernet ops struct during unregister

bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=12dfdf47d00000
start commit: acf25aa6 Merge tag 'Smack-for-5.8' of git://github.com/csc..
git tree: upstream
If the result looks correct, please mark the issue as fixed by replying with:

#syz fix: netfilter: arptables: use pernet ops struct during unregister

Matthew Wilcox

unread,
Jun 7, 2021, 12:59:24ā€ÆPM6/7/21
to syzbot, bjorn.a...@linaro.org, brooke...@gmail.com, core...@netfilter.org, da...@davemloft.net, dsa...@kernel.org, duch...@gmail.com, ebig...@kernel.org, f...@strlen.de, gre...@linuxfoundation.org, kad...@netfilter.org, ku...@kernel.org, linux-...@vger.kernel.org, manivannan...@linaro.org, net...@vger.kernel.org, netfilt...@vger.kernel.org, pa...@netfilter.org, sk...@linuxfoundation.org, syzkall...@googlegroups.com, yosh...@linux-ipv6.org
On Mon, Jun 07, 2021 at 09:47:07AM -0700, syzbot wrote:
> syzbot suspects this issue was fixed by commit:
>
> commit 43016d02cf6e46edfc4696452251d34bba0c0435
> Author: Florian Westphal <f...@strlen.de>
> Date: Mon May 3 11:51:15 2021 +0000
>
> netfilter: arptables: use pernet ops struct during unregister

Same wrong bisection.

#syz fix: qrtr: Convert qrtr_ports from IDR to XArray
Reply all
Reply to author
Forward
0 new messages