From: Stefano Garzarella <sgarz...@redhat.com> Date: Wed, 12 Aug 2020 14:56:02 +0200
> syzbot reported this issue where in the vsock_poll() we find the > socket state at TCP_ESTABLISHED, but 'transport' is null: > general protection fault, probably for non-canonical address > 0xdffffc0000000012: 0000 [#1] PREEMPT SMP KASAN > KASAN: null-ptr-deref in range [0x0000000000000090-0x0000000000000097] > CPU: 0 PID: 8227 Comm: syz-executor.2 Not tainted 5.8.0-rc7-syzkaller #0 > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS > Google 01/01/2011 > RIP: 0010:vsock_poll+0x75a/0x8e0 net/vmw_vsock/af_vsock.c:1038 > Call Trace: > sock_poll+0x159/0x460 net/socket.c:1266 > vfs_poll include/linux/poll.h:90 [inline] > do_pollfd fs/select.c:869 [inline] > do_poll fs/select.c:917 [inline] > do_sys_poll+0x607/0xd40 fs/select.c:1011 > __do_sys_poll fs/select.c:1069 [inline] > __se_sys_poll fs/select.c:1057 [inline] > __x64_sys_poll+0x18c/0x440 fs/select.c:1057 > do_syscall_64+0x60/0xe0 arch/x86/entry/common.c:384 > entry_SYSCALL_64_after_hwframe+0x44/0xa9 > > This issue can happen if the TCP_ESTABLISHED state is set after we read > the vsk->transport in the vsock_poll(). > > We could put barriers to synchronize, but this can only happen during > connection setup, so we can simply check that 'transport' is valid. > > Fixes: c0cfa2d8a788 ("vsock: add multi-transports support") > Reported-and-tested-by: syzbot+a61bac2fcc1a7c662...@syzkaller.appspotmail.com > Signed-off-by: Stefano Garzarella <sgarz...@redhat.com> Applied and queued up for -stable, thank you.