io_uring: check for non-NULL file pointer in io_file_can_poll()

In the Linux kernel, the following vulnerability has been resolved:

io_uring: check for non-NULL file pointer in io_file_can_poll()

In earlier kernels, it was possible to trigger a NULL pointer

dereference off the forced async preparation path, if no file had

been assigned. The trace leading to that looks as follows:

BUG: kernel NULL pointer dereference, address: 00000000000000b0

PGD 0 P4D 0

Oops: 0000 [#1] PREEMPT SMP

CPU: 67 PID: 1633 Comm: buf-ring-invali Not tainted 6.8.0-rc3+ #1

Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS unknown 2/2/2022

RIP: 0010:io_buffer_select+0xc3/0x210

Code: 00 00 48 39 d1 0f 82 ae 00 00 00 48 81 4b 48 00 00 01 00 48 89 73 70 0f b7 50 0c 66 89 53 42 85 ed 0f 85 d2 00 00 00 48 8b 13 <48> 8b 92 b0 00 00 00 48 83 7a 40 00 0f 84 21 01 00 00 4c 8b 20 5b

RSP: 0018:ffffb7bec38c7d88 EFLAGS: 00010246

RAX: ffff97af2be61000 RBX: ffff97af234f1700 RCX: 0000000000000040

RDX: 0000000000000000 RSI: ffff97aecfb04820 RDI: ffff97af234f1700

RBP: 0000000000000000 R08: 0000000000200030 R09: 0000000000000020

R10: ffffb7bec38c7dc8 R11: 000000000000c000 R12: ffffb7bec38c7db8

R13: ffff97aecfb05800 R14: ffff97aecfb05800 R15: ffff97af2be5e000

FS: 00007f852f74b740(0000) GS:ffff97b1eeec0000(0000) knlGS:0000000000000000

CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033

CR2: 00000000000000b0 CR3: 000000016deab005 CR4: 0000000000370ef0

Call Trace:

<TASK>

? __die+0x1f/0x60

? page_fault_oops+0x14d/0x420

? do_user_addr_fault+0x61/0x6a0

? exc_page_fault+0x6c/0x150

? asm_exc_page_fault+0x22/0x30

? io_buffer_select+0xc3/0x210

__io_import_iovec+0xb5/0x120

io_readv_prep_async+0x36/0x70

io_queue_sqe_fallback+0x20/0x260

io_submit_sqes+0x314/0x630

__do_sys_io_uring_enter+0x339/0xbc0

? __do_sys_io_uring_register+0x11b/0xc50

? vm_mmap_pgoff+0xce/0x160

do_syscall_64+0x5f/0x180

entry_SYSCALL_64_after_hwframe+0x46/0x4e

RIP: 0033:0x55e0a110a67e

Code: ba cc 00 00 00 45 31 c0 44 0f b6 92 d0 00 00 00 31 d2 41 b9 08 00 00 00 41 83 e2 01 41 c1 e2 04 41 09 c2 b8 aa 01 00 00 0f 05 <c3> 90 89 30 eb a9 0f 1f 40 00 48 8b 42 20 8b 00 a8 06 75 af 85 f6

because the request is marked forced ASYNC and has a bad file fd, and

hence takes the forced async prep path.

Current kernels with the request async prep cleaned up can no longer hit

this issue, but for ease of backporting, let's add this safety check in

here too as it really doesn't hurt. For both cases, this will inevitably

end with a CQE posted with -EBADF.