Re: KASAN: use-after-free Read in unix_dgram_poll

[Al Viro]

On Sun, Mar 03, 2019 at 02:22:04AM -0800, syzbot wrote:
> Hello,
> 
> syzbot found the following crash on:
> 
> HEAD commit:    7d762d69145a afs: Fix manually set volume location server ..
> git tree:       upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=131d832ac00000
> kernel config:  https://syzkaller.appspot.com/x/.config?x=b76ec970784287c
> dashboard link: https://syzkaller.appspot.com/bug?extid=503d4cc169fcec1cb18c
> compiler:       gcc (GCC) 9.0.0 20181231 (experimental)
> syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=11934262c00000
> 
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+503d4cc169fcec1cb18c@xxxxxxxxxxxxxxxxxxxxxxxxx
> 
> ==================================================================
> BUG: KASAN: use-after-free in unix_dgram_poll+0x5e1/0x690
> net/unix/af_unix.c:2695
> Read of size 4 at addr ffff88809292aae0 by task syz-executor.1/18946
> 
> CPU: 0 PID: 18946 Comm: syz-executor.1 Not tainted 5.0.0-rc8+ #88
> 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+0x172/0x1f0 lib/dump_stack.c:113
>  print_address_description.cold+0x7c/0x20d mm/kasan/report.c:187
>  kasan_report.cold+0x1b/0x40 mm/kasan/report.c:317
>  __asan_report_load4_noabort+0x14/0x20 mm/kasan/generic_report.c:134
>  unix_dgram_poll+0x5e1/0x690 net/unix/af_unix.c:2695
>  sock_poll+0x291/0x340 net/socket.c:1127
>  vfs_poll include/linux/poll.h:86 [inline]
>  aio_poll fs/aio.c:1766 [inline]
>  __io_submit_one fs/aio.c:1876 [inline]
>  io_submit_one+0xe3e/0x1cf0 fs/aio.c:1909
>  __do_sys_io_submit fs/aio.c:1954 [inline]
>  __se_sys_io_submit fs/aio.c:1924 [inline]
>  __x64_sys_io_submit+0x1bd/0x580 fs/aio.c:1924
>  ? 0xffffffff81000000
>  do_syscall_64+0x103/0x610 arch/x86/entry/common.c:290
>  entry_SYSCALL_64_after_hwframe+0x49/0xbe

Apparently, a call of ->poll() overlapping with call of ->release()
(if not outright happening after it).  Which should never happen...

Maybe unrelated to this bug, but...  What's to prevent a wakeup
that happens just after we'd been added to a waitqueue by ->poll()
triggering aio_poll_wake(), which gets to aio_poll_complete()
with its fput() *before* we'd reached the end of ->poll() instance?

I wonder if adding
	get_file(req->file);  // make sure that early completion is safe
right after
        req->file = fget(iocb->aio_fildes);
        if (unlikely(!req->file))
                return -EBADF;
paired with
	fput(req->file);
right after out: in aio_poll() is needed...  Am I missing something
obvious here?  Christoph?