In the Linux kernel, the following vulnerability has been resolved:
iouring: Fix a null-ptr-deref in iotctxexitcb()
Syzkaller reports a NULL deref bug as follows:
BUG: KASAN: null-ptr-deref in iotctxexit_cb+0x53/0xd3 Read of size 4 at addr 0000000000000138 by task file1/1955
CPU: 1 PID: 1955 Comm: file1 Not tainted 6.1.0-rc7-00103-gef4d3ea40565 #75 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-2.el7 04/01/2014 Call Trace: <TASK> dumpstacklvl+0xcd/0x134 ? iotctxexitcb+0x53/0xd3 kasanreport+0xbb/0x1f0 ? iotctxexitcb+0x53/0xd3 kasancheckrange+0x140/0x190 iotctxexitcb+0x53/0xd3 taskworkrun+0x164/0x250 ? taskworkcancel+0x30/0x30 getsignal+0x1c3/0x2440 ? lockdowngrade+0x6e0/0x6e0 ? lockdowngrade+0x6e0/0x6e0 ? exitsignals+0x8b0/0x8b0 ? dorawreadunlock+0x3b/0x70 ? dorawspinunlock+0x50/0x230 archdosignalorrestart+0x82/0x2470 ? kmemcachefree+0x260/0x4b0 ? putname+0xfe/0x140 ? getsigframesize+0x10/0x10 ? doexecveatcommon.isra.0+0x226/0x710 ? lockdephardirqson+0x79/0x100 ? putname+0xfe/0x140 ? doexecveatcommon.isra.0+0x238/0x710 exittousermodeprepare+0x15f/0x250 syscallexittousermode+0x19/0x50 dosyscall64+0x42/0xb0 entrySYSCALL64afterhwframe+0x63/0xcd RIP: 0023:0x0 Code: Unable to access opcode bytes at 0xffffffffffffffd6. RSP: 002b:00000000fffb7790 EFLAGS: 00000200 ORIGRAX: 000000000000000b RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 </TASK> Kernel panic - not syncing: panicon_warn set ...
This happens because the adding of taskwork from ioringexitwork() isn't synchronized with canceling all work items from eg exec. The execution of the two are ordered in that they are both run by the task itself, but if iotctxexitcb() is queued while we're canceling all work items off exec AND gets executed when the task exits to userspace rather than in the main loop in iouringcancelgeneric(), then we can find current->io_uring == NULL and hit the above crash.
It's safe to add this NULL check here, because the execution of the two paths are done by the task itself.
[axboe: add code comment and also put an explanation in the commit msg]