* sctp: suspicious rcu_dereference_check() usage in sctp_epaddr_lookup_transport
@ 2016-12-13 18:07 Dmitry Vyukov
2016-12-13 21:37 ` Marcelo Ricardo Leitner
0 siblings, 1 reply; 3+ messages in thread
From: Dmitry Vyukov @ 2016-12-13 18:07 UTC (permalink / raw)
To: Vladislav Yasevich, Neil Horman, David Miller, linux-sctp,
netdev, LKML, Eric Dumazet, Marcelo Ricardo Leitner
Cc: syzkaller
Hello,
I am getting the following reports while running syzkaller fuzzer:
[ INFO: suspicious RCU usage. ]
4.9.0+ #85 Not tainted
-------------------------------
./include/linux/rhashtable.h:572 suspicious rcu_dereference_check() usage!
other info that might help us debug this:
rcu_scheduler_active = 1, debug_locks = 0
1 lock held by syz-executor1/18023:
#0: (sk_lock-AF_INET){+.+.+.}, at: [< inline >] lock_sock
include/net/sock.h:1454
#0: (sk_lock-AF_INET){+.+.+.}, at: [<ffffffff87bb3ccf>]
sctp_getsockopt+0x45f/0x6800 net/sctp/socket.c:6432
stack backtrace:
CPU: 2 PID: 18023 Comm: syz-executor1 Not tainted 4.9.0+ #85
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
Call Trace:
[< inline >] __dump_stack lib/dump_stack.c:15
[< none >] dump_stack+0x2ee/0x3ef lib/dump_stack.c:51
[< none >] lockdep_rcu_suspicious+0x139/0x180
kernel/locking/lockdep.c:4448
[< inline >] __rhashtable_lookup ./include/linux/rhashtable.h:572
[< inline >] rhltable_lookup ./include/linux/rhashtable.h:660
[< none >] sctp_epaddr_lookup_transport+0x641/0x930
net/sctp/input.c:946
[< none >] sctp_endpoint_lookup_assoc+0x83/0x120
net/sctp/endpointola.c:335
[< none >] sctp_addr_id2transport+0xaf/0x1e0 net/sctp/socket.c:241
[< none >] sctp_getsockopt_peer_addr_info+0x216/0x630
net/sctp/socket.c:4625
[< none >] sctp_getsockopt+0x2860/0x6800 net/sctp/socket.c:6500
[< none >] sock_common_getsockopt+0x9a/0xe0 net/core/sock.c:2685
[< inline >] SYSC_getsockopt net/socket.c:1819
[< none >] SyS_getsockopt+0x245/0x380 net/socket.c:1801
[< none >] entry_SYSCALL_64_fastpath+0x23/0xc6
arch/x86/entry/entry_64.S:203
On commit e7aa8c2eb11ba69b1b69099c3c7bd6be3087b0ba (Dec 12).
^ permalink raw reply [flat|nested] 3+ messages in thread* Re: sctp: suspicious rcu_dereference_check() usage in sctp_epaddr_lookup_transport 2016-12-13 18:07 sctp: suspicious rcu_dereference_check() usage in sctp_epaddr_lookup_transport Dmitry Vyukov @ 2016-12-13 21:37 ` Marcelo Ricardo Leitner 2016-12-14 10:04 ` Xin Long 0 siblings, 1 reply; 3+ messages in thread From: Marcelo Ricardo Leitner @ 2016-12-13 21:37 UTC (permalink / raw) To: Dmitry Vyukov Cc: Vladislav Yasevich, Neil Horman, David Miller, linux-sctp, netdev, LKML, Eric Dumazet, syzkaller, Xin Long On Tue, Dec 13, 2016 at 07:07:01PM +0100, Dmitry Vyukov wrote: > Hello, > > I am getting the following reports while running syzkaller fuzzer: > > [ INFO: suspicious RCU usage. ] > 4.9.0+ #85 Not tainted > ------------------------------- > ./include/linux/rhashtable.h:572 suspicious rcu_dereference_check() usage! > > other info that might help us debug this: > > rcu_scheduler_active = 1, debug_locks = 0 > 1 lock held by syz-executor1/18023: > #0: (sk_lock-AF_INET){+.+.+.}, at: [< inline >] lock_sock > include/net/sock.h:1454 > #0: (sk_lock-AF_INET){+.+.+.}, at: [<ffffffff87bb3ccf>] > sctp_getsockopt+0x45f/0x6800 net/sctp/socket.c:6432 > > stack backtrace: > CPU: 2 PID: 18023 Comm: syz-executor1 Not tainted 4.9.0+ #85 > Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011 > Call Trace: > [< inline >] __dump_stack lib/dump_stack.c:15 > [< none >] dump_stack+0x2ee/0x3ef lib/dump_stack.c:51 > [< none >] lockdep_rcu_suspicious+0x139/0x180 > kernel/locking/lockdep.c:4448 > [< inline >] __rhashtable_lookup ./include/linux/rhashtable.h:572 > [< inline >] rhltable_lookup ./include/linux/rhashtable.h:660 > [< none >] sctp_epaddr_lookup_transport+0x641/0x930 > net/sctp/input.c:946 I think this was introduced in the rhlist converstion. We had removed some rcu_read_lock() calls on sctp stack because rhashtable was already calling it, but then we didn't add them back when moving to rhlist. This code: +/* return a transport without holding it, as it's only used under sock lock */ struct sctp_transport *sctp_epaddr_lookup_transport( const struct sctp_endpoint *ep, const union sctp_addr *paddr) { struct net *net = sock_net(ep->base.sk); + struct rhlist_head *tmp, *list; + struct sctp_transport *t; struct sctp_hash_cmp_arg arg = { - .ep = ep, .paddr = paddr, .net = net, + .lport = htons(ep->base.bind_addr.port), }; - return rhashtable_lookup_fast(&sctp_transport_hashtable, &arg, - sctp_hash_params); + list = rhltable_lookup(&sctp_transport_hashtable, &arg, + sctp_hash_params); Had an implicit rcu_read_lock() on rhashtable_lookup_fast, but it doesn't on rhltable_lookup and rhltable_lookup uses _rcu calls which assumes we have rcu read protection. Marcelo ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: sctp: suspicious rcu_dereference_check() usage in sctp_epaddr_lookup_transport 2016-12-13 21:37 ` Marcelo Ricardo Leitner @ 2016-12-14 10:04 ` Xin Long 0 siblings, 0 replies; 3+ messages in thread From: Xin Long @ 2016-12-14 10:04 UTC (permalink / raw) To: Marcelo Ricardo Leitner Cc: Dmitry Vyukov, Vladislav Yasevich, Neil Horman, David Miller, linux-sctp, netdev, LKML, Eric Dumazet, syzkaller On Wed, Dec 14, 2016 at 5:37 AM, Marcelo Ricardo Leitner <marcelo.leitner@gmail.com> wrote: > On Tue, Dec 13, 2016 at 07:07:01PM +0100, Dmitry Vyukov wrote: >> Hello, >> >> I am getting the following reports while running syzkaller fuzzer: >> >> [ INFO: suspicious RCU usage. ] >> 4.9.0+ #85 Not tainted >> ------------------------------- >> ./include/linux/rhashtable.h:572 suspicious rcu_dereference_check() usage! >> >> other info that might help us debug this: >> >> rcu_scheduler_active = 1, debug_locks = 0 >> 1 lock held by syz-executor1/18023: >> #0: (sk_lock-AF_INET){+.+.+.}, at: [< inline >] lock_sock >> include/net/sock.h:1454 >> #0: (sk_lock-AF_INET){+.+.+.}, at: [<ffffffff87bb3ccf>] >> sctp_getsockopt+0x45f/0x6800 net/sctp/socket.c:6432 >> >> stack backtrace: >> CPU: 2 PID: 18023 Comm: syz-executor1 Not tainted 4.9.0+ #85 >> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011 >> Call Trace: >> [< inline >] __dump_stack lib/dump_stack.c:15 >> [< none >] dump_stack+0x2ee/0x3ef lib/dump_stack.c:51 >> [< none >] lockdep_rcu_suspicious+0x139/0x180 >> kernel/locking/lockdep.c:4448 >> [< inline >] __rhashtable_lookup ./include/linux/rhashtable.h:572 >> [< inline >] rhltable_lookup ./include/linux/rhashtable.h:660 >> [< none >] sctp_epaddr_lookup_transport+0x641/0x930 >> net/sctp/input.c:946 > > I think this was introduced in the rhlist converstion. We had removed > some rcu_read_lock() calls on sctp stack because rhashtable was already > calling it, but then we didn't add them back when moving to rhlist. > > This code: > +/* return a transport without holding it, as it's only used under sock lock */ > struct sctp_transport *sctp_epaddr_lookup_transport( > const struct sctp_endpoint *ep, > const union sctp_addr *paddr) > { > struct net *net = sock_net(ep->base.sk); > + struct rhlist_head *tmp, *list; > + struct sctp_transport *t; > struct sctp_hash_cmp_arg arg = { > - .ep = ep, > .paddr = paddr, > .net = net, > + .lport = htons(ep->base.bind_addr.port), > }; > > - return rhashtable_lookup_fast(&sctp_transport_hashtable, &arg, > - sctp_hash_params); > + list = rhltable_lookup(&sctp_transport_hashtable, &arg, > + sctp_hash_params); > > Had an implicit rcu_read_lock() on rhashtable_lookup_fast, but it > doesn't on rhltable_lookup and rhltable_lookup uses _rcu calls which > assumes we have rcu read protection. You're right, we need to call rcu_read_lock before using rhltable_lookup. will post a fix for it, thanks. ^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2016-12-14 10:05 UTC | newest] Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2016-12-13 18:07 sctp: suspicious rcu_dereference_check() usage in sctp_epaddr_lookup_transport Dmitry Vyukov 2016-12-13 21:37 ` Marcelo Ricardo Leitner 2016-12-14 10:04 ` Xin Long
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).