Look up another CVE · open CVE-2026-89793 in the interactive tracker
CVE-2026-89793
ublk: clear VM_MAYWRITE on read-only ublk char device mmap
Published 2026-09-16 (33 days ago) by the Linux kernel CNA. Subsystem drivers/block. Debian urgency: not yet assigned.
What to do, per Debian release
Debian's own status for CVE-2026-89793 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 | vulnerable | 6.1.190-1 | No fix published anywhere yet, neither in Debian nor upstream for the series bookworm tracks. Watch the Debian tracker page for this CVE. Advisories for bookworm have historically landed a median of 23 days after publication. |
| 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
ublk_ch_mmap() rejects mmap requests with VM_WRITE set, but never clears VM_MAYWRITE on the resulting read-only mapping. This allows a userspace daemon to mmap the per-queue command buffer PROT_READ, then upgrade it to PROT_WRITE via mprotect(), since VM_MAYWRITE was never cleared. The command buffer holds struct ublksrv_io_desc entries that are kernel-written ABI; a writable mapping lets an unprivileged daemon process corrupt fields such as addr, op_flags, nr_sectors, and start_sector. Same bug class as the drm/panthor and drm/vc4 VM_MAYWRITE fixes, and the 2026-08-13 ptp/vmclock fix (a5edadbae57e). Verified via mprotect() PoC: before the fix, a PROT_READ mapping can be upgraded to PROT_READ|PROT_WRITE and a write into the command buffer corrupts io_desc fields (confirmed under KASAN). After the fix, mprotect() returns -EACCES.
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/block/ublk_drv.c
- What this is
- UBLK USERSPACE BLOCK DRIVERMAINTAINERS section matched on drivers/block/ublk_drv.c · linux-block@vger.kernel.org · Maintained
- Kernel module
- ublk_drv
Check it on the machine
grep -w CONFIG_BLK_DEV_UBLK /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 ublk_drvPrints 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 does not build this code in 1 release. It does build it in 4 releases, so the answer depends on which release the machine runs.
- bookwormn
- trixie, forky, sid, bookworm · linux-6.12m
- n
- not enabled on any flavour - this release does not build the code
- m
- a loadable module on every flavour - check lsmod, can be blacklisted
- Build switch
- CONFIG_BLK_DEV_UBLK
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-16 (33 days ago)source
- CVSS
- 7.8 high
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:Hsource recompute it - Attack vector
- local (AV:L)source
- EPSS
- 0.17%, higher than 5.7% of all CVEssource
- CISA KEV
- not listedthe KEV catalogue
- Debian urgency
- not yet assignedsource
- Subsystem
- drivers/block
Upstream fixes
The versions the CNA records as introducing and fixing this, and the commit for each. source
| Introduced | Fixed in | Commit |
|---|---|---|
| 6.0 | 6.6.157 | be41733c24be |
| 6.0 | 6.12.110 | 5befd06a7221 |
| 6.0 | 6.18.51 | e373c1acdbcf |
| 6.0 | 7.2.5 | fa5e1bc673ca |
| 6.0 | 7.3 | 6e2b571b0a54 |
Debian advisories
| Advisory | Date | Shipped to | Debian |
|---|---|---|---|
| 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
- The bug is reached only through local syscalls: open of /dev/ublkcN (created via /dev/ublk-control), mmap(PROT_READ) of the per-queue command buffer in ublk_ch_mmap(), then mprotect(PROT_WRITE). There is no network, Bluetooth, or physical-bus path into this mmap handler.
- AC:LAttack complexity, low
- The attacker fully controls every step: mmap PROT_READ, mprotect PROT_WRITE, and write through the remap_pfn_range PFNMAP. mprotect upgrades the VMA because VM_MAYWRITE was left set (mm/mprotect.c), with no race, special layout, or victim state required.
- PR:LPrivileges required, low
- ublk_ctrl_add_dev() lets a caller without CAP_SYS_ADMIN create a device with UBLK_F_UNPRIVILEGED_DEV, and ublk_ch_open() has no capability check, so an ordinary local user or a delegated unprivileged ublk daemon can open /dev/ublkcN and mmap the command buffer.
- UI:NUser interaction, none
- The attacking process performs the full create/open/mmap/mprotect/write sequence itself and can issue I/O to its own ublk disk to drive kernel re-reads of the corrupted descriptors. No other user must mount, open, or otherwise interact.
- S:UScope, unchanged
- The corrupted io_cmd_buf pages and the ublk/block I/O path that consumes them all sit in the host kernel's security authority. This is standard local kernel memory corruption, not a VM, IOMMU, or hypervisor boundary escape.
- C:HConfidentiality impact, high
- The kernel re-reads iod->op_flags via ublk_iod_is_shmem_zc() on completion; setting UBLK_IO_F_SHMEM_ZC skips ublk_unmap_io(), so READ bios complete with uninitialized request/page-cache pages. That is the same uninitialized kernel-memory leak UBLK_F_SUPPORT_ZERO_COPY was denied to unprivileged devices to prevent.
- I:HIntegrity impact, high
- After mprotect, userspace has a writable PFNMAP of kernel-allocated io_cmd_buf pages and can overwrite kernel-written ublksrv_io_desc fields (op_flags, addr, nr_sectors, start_sector). The kernel then trusts op_flags to skip map/unmap, corrupting the block I/O data path for every consumer of that ublk disk.
- A:HAvailability impact, high
- Clearing SHMEM_ZC with a null io->buf.addr forces ublk_start_io() into the mapped_bytes==0 requeue loop and stalls the request queue; completing I/O against corrupted descriptors or uninitialized pages can oops or hang the kernel. Attacker-triggerable kernel hang or crash is High.