* 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).