CVE-2023-54288

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

wifi: mac80211: fortify the spinlock against deadlock by interrupt

In the function ieee80211txdequeue() there is a particular locking sequence:

begin: spinlock(&local->queuestopreasonlock); qstopped = local->queuestopreasons[q]; spinunlock(&local->queuestopreason_lock);

However small the chance (increased by ftracetest), an asynchronous interrupt can occur in between of spinlock() and spinunlock(), and the interrupt routine will attempt to lock the same &local->queuestopreason_lock again.

This will cause a costly reset of the CPU and the wifi device or an altogether hang in the single CPU and single core scenario.

The only remaining spinlock(&local->queuestopreasonlock) that did not disable interrupts was patched, which should prevent any deadlocks on the same CPU/core and the same wifi device.

This is the probable trace of the deadlock:

kernel: ================================ kernel: WARNING: inconsistent lock state kernel: 6.3.0-rc6-mt-20230401-00001-gf86822a1170f #4 Tainted: G W kernel: -------------------------------- kernel: inconsistent {IN-SOFTIRQ-W} -> {SOFTIRQ-ON-W} usage. kernel: kworker/5:0/25656 [HC0[0]:SC0[0]:HE1:SE1] takes: kernel: ffff9d6190779478 (&local->queuestopreasonlock){+.?.}-{2:2}, at: returntohandler+0x0/0x40 kernel: {IN-SOFTIRQ-W} state was registered at: kernel: lockacquire+0xc7/0x2d0 kernel: rawspinlock+0x36/0x50 kernel: ieee80211txdequeue+0xb4/0x1330 [mac80211] kernel: iwlmvmmacitxqxmit+0xae/0x210 [iwlmvm] kernel: iwlmvmmacwaketxqueue+0x2d/0xd0 [iwlmvm] kernel: ieee80211queueskb+0x450/0x730 [mac80211] kernel: _ieee80211xmitfast.constprop.66+0x834/0xa50 [mac80211] kernel: _ieee80211subifstartxmit+0x217/0x530 [mac80211] kernel: ieee80211subifstartxmit+0x60/0x580 [mac80211] kernel: devhardstartxmit+0xb5/0x260 kernel: _devqueuexmit+0xdbe/0x1200 kernel: neighresolveoutput+0x166/0x260 kernel: ipfinishoutput2+0x216/0xb80 kernel: _ipfinishoutput+0x2a4/0x4d0 kernel: ipfinishoutput+0x2d/0xd0 kernel: ipoutput+0x82/0x2b0 kernel: iplocalout+0xec/0x110 kernel: igmpv3sendpack+0x5c/0x90 kernel: igmpifctimerexpire+0x26e/0x4e0 kernel: calltimerfn+0xa5/0x230 kernel: runtimersoftirq+0x27f/0x550 kernel: _dosoftirq+0xb4/0x3a4 kernel: irqexitrcu+0x9b/0xc0 kernel: sysvecapictimerinterrupt+0x80/0xa0 kernel: asmsysvecapictimerinterrupt+0x1f/0x30 kernel: _rawspinunlockirqrestore+0x3f/0x70 kernel: freetopartiallist+0x3d6/0x590 kernel: _slabfree+0x1b7/0x310 kernel: kmemcachefree+0x52d/0x550 kernel: putname+0x5d/0x70 kernel: dosysopenat2+0x1d7/0x310 kernel: dosysopen+0x51/0x80 kernel: _x64sysopenat+0x24/0x30 kernel: dosyscall64+0x5c/0x90 kernel: entrySYSCALL64afterhwframe+0x72/0xdc kernel: irq event stamp: 5120729 kernel: hardirqs last enabled at (5120729): [<ffffffff9d149936>] tracegraphreturn+0xd6/0x120 kernel: hardirqs last disabled at (5120728): [<ffffffff9d149950>] tracegraphreturn+0xf0/0x120 kernel: softirqs last enabled at (5069900): [<ffffffff9cf65b60>] returntohandler+0x0/0x40 kernel: softirqs last disabled at (5067555): [<ffffffff9cf65b60>] returntohandler+0x0/0x40 kernel: other info that might help us debug this: kernel: Possible unsafe locking scenario: kernel: CPU0 kernel: ---- kernel: lock(&local->queuestopreasonlock); kernel: <Interrupt> kernel: lock(&local->queuestopreasonlock); kernel: * DEADLOCK * kernel: 8 locks held by kworker/5:0/25656: kernel: #0: ffff9d618009d138 ((wqcompletion)eventsfreezable){+.+.}-{0:0}, at: processonework+0x1ca/0x530 kernel: #1: ffffb1ef4637fe68 ((workcompletion)(&local->restartwork)){+.+.}-{0:0}, at: processonework+0x1ce/0x530 kernel: #2: ffffffff9f166548 (rtnlmutex){+.+.}-{3:3}, at: returnto_handler+0x0/0x40 kernel: #3: ffff9d619 ---truncated---