CVE-2026-93054: uio: Fix stale info pointer in failed registration path
In the Linux kernel, the following vulnerability has been resolved:
uio: Fix stale info pointer in failed registration path
After deviceadd(), the UIO device is visible to userspace and /dev/uioX can be opened. If a later setup step fails, uioregisterdevice() unwinds the device but leaves idev->info pointing at the caller-owned struct uioinfo.
That is unsafe when an opener races with the failed registration path. The open file keeps a reference to the uiodevice, while the caller sees registration failure and may free its struct uioinfo. Later file operations can then follow idev->info and dereference freed memory.
Handle post-deviceadd() failures like unregister: remove UIO attributes while the info pointer is still valid, then clear idev->info under infolock and wake existing waiters/async users before removing the device and minor. This makes already-open file descriptors observe the same "device gone" state as normal uiounregisterdevice().
Affected Software
Event History
Frequently Asked Questions
What conditions are required for this issue to be exploitable?
A UIO device registration must fail after device_add() has made the device visible to userspace. A userspace process must open the exposed /dev/uioX node before the failed registration path finishes, while the caller can free the associated struct uio_info.
What is the impact on a process that opened the device during the failed registration?
Its open file retains a reference to the UIO device, but later file operations can dereference the freed uio_info through idev->info. This creates a use-after-free condition.
How does the fix affect file descriptors that were already opened?
The fix clears the info pointer under the info lock and wakes waiters and asynchronous users before removing the device and minor. Existing descriptors then observe the same device-gone state used by normal UIO device unregistration.