CVE-2026-93054
High · 7.0CVSS
7.0
EPSS
0.1%
Published
Sep 17, 2026
CISA due date
—
Cloudanix analysis
A timing problem in the Linux kernel's handling of certain hardware device registrations could let a local user crash the machine or run harmful code.
- Exploitation
- Local Privilege
- Attacker needs
- Low Privilege
- Complexity
- High
- Impact
- Full Compromise
- Component
- OS kernel
- Class
- Use After Free
- Remediation
- Patch
- Effort
- Medium
- Patch risk
- Low
What it actually does
Stale pointer to caller-owned uio_info structure left after post-device_add failure in __uio_register_device allows use-after-free when an open file descriptor races with the unwind and later performs operations on the uio_device.
Why it matters to the business
Local attackers on Linux systems exposing UIO devices may crash the kernel or achieve arbitrary code execution, risking denial of service or full host compromise; low EPSS and no known exploitation reduce immediate urgency but patch promptly on affected kernels.
How an attack unfolds
Attacker triggers a UIO device registration that succeeds at device_add but fails a subsequent step; concurrently opens the resulting /dev/uioX while the failure path frees the info structure without clearing the pointer, then uses the dangling reference in file operations to dereference freed memory.
How to fix it
Upgrade to a kernel containing the fix that removes UIO attributes, clears idev->info under info_lock, wakes waiters, and only then removes the device on registration failure; rebuild and reboot with the corrected kernel.
How to confirm the fix worked
Confirm the running kernel source or binary incorporates the described post-device_add failure handling under info_lock; exercise concurrent open and failing registration scenarios to verify the pointer is cleared before any possible free.
Typical attack path
- Locate or trigger code paths performing __uio_register_device
- Cause a post-device_add setup failure
- Race an open on the newly created /dev/uioX minor
- Retain the file descriptor and issue operations that follow the stale info pointer
How to detect it
Search kernel logs for oops/panic traces referencing uio_device, uio_info, or __uio_register_device around device registration failures; inspect audit logs for unusual opens of /dev/uio* minors followed by process crashes or privilege changes.
What your security team should do
- Apply the corrected kernel as soon as available for your distribution
- Limit unprivileged access to /dev/uio* devices via udev or LSM policy where feasible
- Review any out-of-tree UIO drivers for analogous registration error paths
The record
In the Linux kernel, the following vulnerability has been resolved: uio: Fix stale info pointer in failed registration path After device_add(), the UIO device is visible to userspace and /dev/uioX can be opened. If a later setup step fails, __uio_register_device() unwinds the device but leaves idev->info pointing at the caller-owned struct uio_info. That is unsafe when an opener races with the failed registration path. The open file keeps a reference to the uio_device, while the caller sees registration failure and may free its struct uio_info. Later file operations can then follow idev->info and dereference freed memory. Handle post-device_add() failures like unregister: remove UIO attributes while the info pointer is still valid, then clear idev->info under info_lock 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 uio_unregister_device().
Affected packages
| Ecosystem | Package | Introduced | Fixed |
|---|