In the Linux kernel, the following vulnerability has been resolved:
ublk: clear VM_MAYWRITE on read-only ublk char device mmap
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.
CVSS Vector: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS Score: 7.8
AV:L - 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:L - 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:L - 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:N - 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:U - 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:H - 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:H - 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:H - 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.
| Attack Vector |
Local |
Scope |
Unchanged |
| Attack Complexity |
Low |
Confidentiality Impact |
High |
| Privileges Required |
Low |
Integrity Impact |
High |
| User Interaction |
None |
Availability Impact |
High |
AV:L - 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:L - 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:L - 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:N - 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:U - 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:H - 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:H - 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:H - 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.
CVSS 3.1