CVE-2026-80824: usb: usbfs: fix use-after-free of usb_device in usbdev_release()
In the Linux kernel, the following vulnerability has been resolved:
usb: usbfs: fix use-after-free of usbdevice in usbdevrelease()
usbdevrelease() drops its reference to the struct usbdevice before draining the list of completed async URBs, but that drain path reads back through the same object: freeasync() calls decusbmemoryusecount() for any URB whose buffer came from the usbfs mmap() region, and its first statement is bustohcd(ps->dev->bus).
After a disconnect the usbfs reference can be the last one, in which case usbputdev() frees the device and the subsequent loop reads offset 80 of freed memory and uses the result as a struct usbhcd , which hcdbufferfreepages() then dereferences.
This is reachable by an unprivileged process that has read/write access to a /dev/bus/usb node: mmap() the fd, submit one URB with a buffer inside the mapping, wait for the device to be unplugged, then munmap() and close(). It reproduces on every attempt rather than being a race, because a live MAPSHARED vma holds a reference on the struct file, so usbdevrelease() cannot run until the last vma is gone and the freeing branch of decusbmemoryusecount() is always taken.
BUG: KASAN: slab-use-after-free in decusbmemoryusecount+0x3ae/0x410 Read of size 8 at addr ffff8880122ee050 by task poc/769 CPU: 1 UID: 1000 PID: 769 Comm: poc Tainted: G B 6.12.94 #3
Call Trace: decusbmemoryusecount+0x3ae/0x410 freeasync+0x2aa/0x4f0 usbdevrelease+0x375/0x460 fput+0x3ea/0xb50 x64sysclose+0x86/0x100
Allocated by task 11: usballocdev+0x55/0xd90 hubevent+0x2524/0x43d0
Freed by task 769: kfree+0x121/0x360 devicerelease+0xd2/0x280 usbputdev+0x23/0x30 usbdevrelease+0x2d8/0x460
Release the device reference after the drain loop instead. Nothing between the two points requires it to have been dropped.
Affected Software
Event History
Frequently Asked Questions
Who can trigger this issue?
An unprivileged local process can trigger it if it has read/write access to a /dev/bus/usb device node. The process must be able to open the node and use usbfs operations on that file descriptor.
What conditions are required for exploitation?
The process maps the usbfs file descriptor, submits an asynchronous URB using a buffer in that mapping, and the USB device is then disconnected. It then unmaps the region and closes the descriptor, causing the completed-URB cleanup path to access a freed usb_device.
Is this only a timing-dependent race?
No. The described sequence reproduces on every attempt rather than depending on a race, because the live MAP_SHARED mapping retains the file reference until the final mapping is removed.
How can I determine whether a system may be exposed?
A system may be exposed if unprivileged users can obtain read/write access to /dev/bus/usb nodes and can interact with removable USB devices. The affected workflow specifically requires usbfs mmap support, asynchronous URB submission with a mapped buffer, and device disconnection.