From: David Howells <dhowells@redhat.com>
To: Eric Dumazet <edumazet@google.com>
Cc: dhowells@redhat.com, "David S . Miller" <davem@davemloft.net>,
netdev <netdev@vger.kernel.org>,
Eric Dumazet <eric.dumazet@gmail.com>,
syzbot <syzkaller@googlegroups.com>
Subject: Re: [PATCH v3 net] rxrpc: fix race condition in rxrpc_input_packet()
Date: Wed, 24 Apr 2019 09:27:10 +0100 [thread overview]
Message-ID: <27703.1556094430@warthog.procyon.org.uk> (raw)
In-Reply-To: <20190424004741.152547-1-edumazet@google.com>
Eric Dumazet <edumazet@google.com> wrote:
> After commit 5271953cad31 ("rxrpc: Use the UDP encap_rcv hook"),
> rxrpc_input_packet() is directly called from lockless UDP receive
> path, under rcu_read_lock() protection.
>
> It must therefore use RCU rules :
>
> - udp_sk->sk_user_data can be cleared at any point in this function.
> rcu_dereference_sk_user_data() is what we need here.
>
> - Also, since sk_user_data might have been set in rxrpc_open_socket()
> we must observe a proper RCU grace period before kfree(local) in
> rxrpc_lookup_local()
>
> syzbot reported :
>
> kasan: CONFIG_KASAN_INLINE enabled
> kasan: GPF could be caused by NULL-ptr deref or user memory access
> general protection fault: 0000 [#1] PREEMPT SMP KASAN
> CPU: 0 PID: 19236 Comm: syz-executor703 Not tainted 5.1.0-rc6 #79
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
> RIP: 0010:__lock_acquire+0xbef/0x3fb0 kernel/locking/lockdep.c:3573
> Code: 00 0f 85 a5 1f 00 00 48 81 c4 10 01 00 00 5b 41 5c 41 5d 41 5e 41 5f 5d c3 48 b8 00 00 00 00 00 fc ff df 4c 89 ea 48 c1 ea 03 <80> 3c 02 00 0f 85 4a 21 00 00 49 81 7d 00 20 54 9c 89 0f 84 cf f4
> RSP: 0018:ffff88809d7aef58 EFLAGS: 00010002
> RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 0000000000000000
> RDX: 0000000000000026 RSI: 0000000000000000 RDI: 0000000000000001
> RBP: ffff88809d7af090 R08: 0000000000000001 R09: 0000000000000001
> R10: ffffed1015d05bc7 R11: ffff888089428600 R12: 0000000000000000
> R13: 0000000000000130 R14: 0000000000000001 R15: 0000000000000001
> FS: 00007f059044d700(0000) GS:ffff8880ae800000(0000) knlGS:0000000000000000
> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 00000000004b6040 CR3: 00000000955ca000 CR4: 00000000001406f0
> Call Trace:
> lock_acquire+0x16f/0x3f0 kernel/locking/lockdep.c:4211
> __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline]
> _raw_spin_lock_irqsave+0x95/0xcd kernel/locking/spinlock.c:152
> skb_queue_tail+0x26/0x150 net/core/skbuff.c:2972
> rxrpc_reject_packet net/rxrpc/input.c:1126 [inline]
> rxrpc_input_packet+0x4a0/0x5536 net/rxrpc/input.c:1414
> udp_queue_rcv_one_skb+0xaf2/0x1780 net/ipv4/udp.c:2011
> udp_queue_rcv_skb+0x128/0x730 net/ipv4/udp.c:2085
> udp_unicast_rcv_skb.isra.0+0xb9/0x360 net/ipv4/udp.c:2245
> __udp4_lib_rcv+0x701/0x2ca0 net/ipv4/udp.c:2301
> udp_rcv+0x22/0x30 net/ipv4/udp.c:2482
> ip_protocol_deliver_rcu+0x60/0x8f0 net/ipv4/ip_input.c:208
> ip_local_deliver_finish+0x23b/0x390 net/ipv4/ip_input.c:234
> NF_HOOK include/linux/netfilter.h:289 [inline]
> NF_HOOK include/linux/netfilter.h:283 [inline]
> ip_local_deliver+0x1e9/0x520 net/ipv4/ip_input.c:255
> dst_input include/net/dst.h:450 [inline]
> ip_rcv_finish+0x1e1/0x300 net/ipv4/ip_input.c:413
> NF_HOOK include/linux/netfilter.h:289 [inline]
> NF_HOOK include/linux/netfilter.h:283 [inline]
> ip_rcv+0xe8/0x3f0 net/ipv4/ip_input.c:523
> __netif_receive_skb_one_core+0x115/0x1a0 net/core/dev.c:4987
> __netif_receive_skb+0x2c/0x1c0 net/core/dev.c:5099
> netif_receive_skb_internal+0x117/0x660 net/core/dev.c:5202
> napi_frags_finish net/core/dev.c:5769 [inline]
> napi_gro_frags+0xade/0xd10 net/core/dev.c:5843
> tun_get_user+0x2f24/0x3fb0 drivers/net/tun.c:1981
> tun_chr_write_iter+0xbd/0x156 drivers/net/tun.c:2027
> call_write_iter include/linux/fs.h:1866 [inline]
> do_iter_readv_writev+0x5e1/0x8e0 fs/read_write.c:681
> do_iter_write fs/read_write.c:957 [inline]
> do_iter_write+0x184/0x610 fs/read_write.c:938
> vfs_writev+0x1b3/0x2f0 fs/read_write.c:1002
> do_writev+0x15e/0x370 fs/read_write.c:1037
> __do_sys_writev fs/read_write.c:1110 [inline]
> __se_sys_writev fs/read_write.c:1107 [inline]
> __x64_sys_writev+0x75/0xb0 fs/read_write.c:1107
> do_syscall_64+0x103/0x610 arch/x86/entry/common.c:290
> entry_SYSCALL_64_after_hwframe+0x49/0xbe
>
> Fixes: 5271953cad31 ("rxrpc: Use the UDP encap_rcv hook")
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Reported-by: syzbot <syzkaller@googlegroups.com>
Acked-by: David Howells <dhowells@redhat.com>
next prev parent reply other threads:[~2019-04-24 8:27 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-04-24 0:47 [PATCH v3 net] rxrpc: fix race condition in rxrpc_input_packet() Eric Dumazet
2019-04-24 8:27 ` David Howells [this message]
2019-04-24 16:40 ` Eric Dumazet
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=27703.1556094430@warthog.procyon.org.uk \
--to=dhowells@redhat.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=eric.dumazet@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=syzkaller@googlegroups.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.