CVE-2026-64453: usb: misc: usbio: fix disconnect UAF in client teardown
In the Linux kernel, the following vulnerability has been resolved:
usb: misc: usbio: fix disconnect UAF in client teardown
usbiodisconnect() walks usbio->clilist in reverse and uninitializes each auxiliary device. auxiliarydeviceuninit() drops the device reference, and for an unbound child that can run usbioauxdevrelease() and free the containing struct usbioclient.
listforeachentryreverse() advances after the loop body by reading client->link.prev. If the current client is freed by auxiliarydeviceuninit(), the iterator dereferences freed memory.
Use listforeachentrysafereverse() so the previous client is cached before the body can drop the final reference. This preserves reverse teardown order while keeping the next iterator cursor independent of the current client's lifetime.
Validation reproduced this kernel report: BUG: KASAN: slab-use-after-free in usbiodisconnect+0x12e/0x150
Call Trace: <TASK> dumpstacklvl+0x66/0xa0 printreport+0xce/0x630 ? usbiodisconnect+0x12e/0x150 ? srsoaliasreturnthunk+0x5/0xfbef5 ? virtaddrvalid+0x188/0x320 ? usbiodisconnect+0x12e/0x150 kasanreport+0xe0/0x110 ? usbiodisconnect+0x12e/0x150 usbiodisconnect+0x12e/0x150 usbunbindinterface+0xf3/0x400 reallyprobe+0x316/0x660 driverprobedevice+0x106/0x240 driverprobedevice+0x4a/0x110 deviceattachdriver+0xf1/0x1a0 ? pfxdeviceattachdriver+0x10/0x10 busforeachdrv+0xf9/0x160 ? pfxbusforeachdrv+0x10/0x10 ? srsoaliasreturnthunk+0x5/0xfbef5 ? tracehardirqson+0x18/0x130 ? srsoaliasreturnthunk+0x5/0xfbef5 ? rawspinunlockirqrestore+0x44/0x60 deviceattach+0x133/0x2a0 ? pfxdeviceattach+0x10/0x10 ? srsoaliasreturnthunk+0x5/0xfbef5 ? dorawspinunlock+0x9a/0x100 ? srsoaliasreturnthunk+0x5/0xfbef5 deviceinitialprobe+0x55/0x70 busprobedevice+0x4a/0xd0 deviceadd+0x9b9/0xc10 ? pfxdeviceadd+0x10/0x10 ? rawspinunlockirqrestore+0x44/0x60 ? srsoaliasreturnthunk+0x5/0xfbef5 ? lockdephardirqsonprepare+0xea/0x1a0 ? srsoaliasreturnthunk+0x5/0xfbef5 ? usbenablelpm+0x3c/0x260 usbsetconfiguration+0xb64/0xf20 usbgenericdriverprobe+0x5f/0x90 usbprobedevice+0x71/0x1b0 reallyprobe+0x46b/0x660 driverprobedevice+0x106/0x240 driverprobedevice+0x4a/0x110 deviceattachdriver+0xf1/0x1a0 ? pfxdeviceattachdriver+0x10/0x10 busforeachdrv+0xf9/0x160 ? pfxbusforeachdrv+0x10/0x10 ? srsoaliasreturnthunk+0x5/0xfbef5 ? tracehardirqson+0x18/0x130 ? srsoaliasreturnthunk+0x5/0xfbef5 ? rawspinunlockirqrestore+0x44/0x60 deviceattach+0x133/0x2a0 ? pfxdeviceattach+0x10/0x10 ? srsoaliasreturnthunk+0x5/0xfbef5 ? dorawspinunlock+0x9a/0x100 ? srsoaliasreturnthunk+0x5/0xfbef5 deviceinitialprobe+0x55/0x70 busprobedevice+0x4a/0xd0 deviceadd+0x9b9/0xc10 ? pfxdeviceadd+0x10/0x10 ? srsoaliasreturnthunk+0x5/0xfbef5 ? adddevicerandomness+0xb7/0xf0 usbnewdevice+0x492/0x870 hubevent+0x1b10/0x29c0 ? pfxhubevent+0x10/0x10 ? srsoaliasreturnthunk+0x5/0xfbef5 ? lockacquire+0x187/0x300 ? processonework+0x475/0xb90 ? srsoaliasreturnthunk+0x5/0xfbef5 ? lockrelease+0xc8/0x290 ? srsoaliasreturnthunk+0x5/0xfbef5 processonework+0x4d7/0xb90 ? pfxprocessonework+0x10/0x10 ? srsoaliasreturnthunk+0x5/0xfbef5 ? srsoaliasreturnthunk+0x5/0xfbef5 ? listaddvalidorreport+0x37/0xf0 ? pfxhubevent+0x10/0x10 ? srsoaliasreturnthunk+0x5/0xfbef5 workerthread+0x2d8/0x570 ? pfxworkerthread+0x10/0x10 kthread+0x1ad/0x1f0 ? pfxkthread+0x10/0x10 retfromfork+0x3c9/0x540 ? pfxretfromfork+0x10/0x10 ? srsoaliasreturnthunk+0x5/0xfbef5 ? switchto+0x2e9/0x730 ? pfxkthread+0x10/0x10 retfromforkasm+0x1a/0x30 </TASK>
Affected Software
Remediation
Event History
Frequently Asked Questions
Who is exposed to this issue?
The CVSS vector indicates local access and low privileges are required. Systems using the Linux kernel USBIO driver are the relevant exposure population.
What conditions are needed to trigger the flaw?
The issue occurs during USBIO client teardown on device disconnect, when an unbound auxiliary child can have its final reference dropped by auxiliary_device_uninit(). The subsequent reverse-list iteration can then access the freed client structure.
How can I identify signs that the system has encountered this problem?
Validation reproduced a KASAN slab-use-after-free report in usbio_disconnect(). Kernel logs containing "KASAN: slab-use-after-free" with usbio_disconnect in the call trace are an indicator of this condition.
Is a fix available?
Yes. A patch is available, and the referenced stable kernel commits provide the fix.