Look up another CVE · open CVE-2026-93054 in the interactive tracker
CVE-2026-93054
uio: Fix stale info pointer in failed registration path
Published 2026-09-17 (31 days ago) by the Linux kernel CNA. Subsystem drivers/uio. Debian urgency: not yet assigned.
What to do, per Debian release
Debian's own status for CVE-2026-93054 in every release this site tracks, and what each one means in practice. Every status below is the one the Debian Security Team publishes for this CVE. source
| Release | Status | Version | What this means |
|---|---|---|---|
| Debian 12bookworm | fixedDLA-4841-1 · 2026-10-17 · text | 6.1.190-1 | Update the kernel and reboot. DLA-4841-1 shipped the fix on 2026-10-17, in 6.1.190-1. A running kernel keeps the old code until the machine restarts. |
| Debian 13trixie | fixedDSA-6528-1 · 2026-09-29 · text | 6.12.111-1 | Update the kernel and reboot. DSA-6528-1 shipped the fix on 2026-09-29, in 6.12.111-1. A running kernel keeps the old code until the machine restarts. |
| Debian 14forky | fixed | 7.2.6-1 | Update the kernel and reboot. Fixed in 7.2.6-1. A running kernel keeps the old code until the machine restarts. |
| Debian unstablesid | fixed | 7.2.6-1 | Update the kernel and reboot. Fixed in 7.2.6-1. A running kernel keeps the old code until the machine restarts. |
| Debian 12bookworm · linux-6.12 | fixedDLA-4817-1 · 2026-10-04 · text | 6.12.111-1~deb12u1 | Update the kernel and reboot. DLA-4817-1 shipped the fix on 2026-10-04, in 6.12.111-1~deb12u1. A running kernel keeps the old code until the machine restarts. |
The vulnerability
What the bug is
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().
Where it lives
The fix touches these files. If the subsystem is one you do not use, the practical exposure is lower, though the package is still the vulnerable one.
drivers/uio/uio.c
- What this is
- USERSPACE I/O (UIO)MAINTAINERS section matched on drivers/uio/ · Maintained
- Kernel module
- uio
Check it on the machine
grep -w CONFIG_UIO /boot/config-$(uname -r)Reads the booted kernel's own configuration, on the machine and nowhere else. =y is built in, =m is a module, and an is not set line means the code is not there.
lsmod | grep -w uioPrints a line if that module is loaded right now, and nothing if it is not. One that is not loaded can still be loaded later by anything that needs it.
Show whether Debian builds this, per release
Debian builds this as a loadable module. Every release below compiles it as a module on every flavour, so whether the code is in the running kernel depends on whether that module is loaded.
- bookworm, trixie, forky, sid, bookworm · linux-6.12m
- m
- a loadable module on every flavour - check lsmod, can be blacklisted
- Build switch
- CONFIG_UIO
From the configuration Debian publishes for every kernel flavour it builds. It covers only the architectures Debian ships a linux-config package for, and nothing about a kernel you built yourself. Debian's own status above stays authoritative about the source package.MAINTAINERS kbuild Makefiles Debian linux-config packages
Signals
- Published
- 2026-09-17 (31 days ago)source
- CVSS
- 7.0 high
CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:Hsource recompute it - Attack vector
- local (AV:L)source
- EPSS
- 0.15%, higher than 3.7% of all CVEssource
- CISA KEV
- not listedthe KEV catalogue
- Debian urgency
- not yet assignedsource
- Subsystem
- drivers/uio
Upstream fixes
The versions the CNA records as introducing and fixing this, and the commit for each. source
| Introduced | Fixed in | Commit |
|---|---|---|
| 4.18 | 5.10.270 | 63eaa7663335 |
| 4.18 | 5.15.221 | df4faf65194e |
| 4.18 | 6.1.188 | 506b43dde5f9 |
| 4.18 | 6.6.157 | 15340b00e665 |
| 4.18 | 6.12.110 | 234156f6c6d9 |
| 4.18 | 6.18.52 | 16695e9059d8 |
| 4.18 | 7.2.6 | ec5bd6731183 |
| 4.18 | 7.3 | 67b6fc084b03 |
| 4.14.100 | 0 | 0 |
Debian advisories
| Advisory | Date | Shipped to | Debian |
|---|---|---|---|
| DLA-4841-1 | 2026-10-17 | bookworm 6.1.190-1 | tracker |
| DLA-4817-1 | 2026-10-04 | bookworm 6.12.111-1~deb12u1 | tracker |
| DSA-6528-1 | 2026-09-29 | trixie 6.12.111-1 | tracker |
Why the CNA scored it this way
Quoted from the kernel CNA's own scoring file, word for word. A highlighted metric carries the most severe value CVSS v3.1 defines for it, which is what pushes the score up. source
- AV:LAttack vector, local
- After device_add() in __uio_register_device(), the char device is opened via open(2) on /dev/uioN into uio_open(); the dangling idev->info is then used by uio_write/uio_mmap/uio_release on that fd. Callers such as tcmu_configure_device() (configfs enable) and uio_pci_generic probe() register locally; no remote protocol carries the trigger.
- AC:HAttack complexity, high
- The stale-info unwind runs only when uio_dev_add_attributes() (kobject_create_and_add/kobject_add/kobject_uevent for maps/portio) or request_threaded_irq() fails after device_add(). Those fail on -ENOMEM, kernfs errors, or IRQ setup failure the attacker cannot force; a successful register never leaves idev->info set after the caller drops struct uio_info.
- PR:LPrivileges required, low
- uio_open() has no capable() check, and uio_pci_generic installs no info->open hook, so the racing open is gated only by /dev/uioN inode mode. Reasonable UIO deployments (DPDK udev, tcmu-runner) grant that node to a non-root account that can also write target_dev_enable_store (TCMU) or hold the fd across a failing probe.
- UI:NUser interaction, none
- The same actor can write target_dev_enable_store (echo 1 > enable -> tcmu_configure_device -> uio_register_device) or bind uio_pci_generic while another thread open()s /dev/uioN and then mmap/write/close; no other user must mount media or confirm a prompt.
- S:UScope, unchanged
- The use-after-free is idev->info in the host UIO core (uio_write/uio_mmap/uio_release) after the caller (e.g. devm unwind of uio_pci_generic's struct uio_pci_generic_dev) frees struct uio_info; impact stays in the host kernel, not a KVM/Xen, IOMMU, or sandbox escape.
- C:HConfidentiality impact, high
- After the caller frees struct uio_info, uio_read and uio_mmap still treat the non-NULL idev->info as live and read info->irq, info->mem[], and related fields. Reclaiming that slab object gives an arbitrary kernel read through those file operations.
- I:HIntegrity impact, high
- uio_write() calls idev->info->irqcontrol, uio_open() calls info->open, and uio_release() calls info->release on the freed uio_info; uio_mmap_physical() feeds info->mem[].addr into remap_pfn_range(). Spraying the object hijacks those function pointers or the PFN map for an arbitrary write/CFI primitive.
- A:HAvailability impact, high
- uio_write/uio_mmap/uio_release and uio_vma_fault dereference the freed idev->info (and TCMU's tcmu_vma_fault uses info->mem[].addr after vfree(mb_addr) on err_register), which oopses or panics the kernel even without a successful spray.