CVE-2026-89793: Linux Kernel ublk Privilege Escalation

CVE-2026-89793 Overview

CVE-2026-89793 is a Linux kernel vulnerability in the userspace block driver (ublk) subsystem. The ublk_ch_mmap() function rejects mmap requests that set VM_WRITE, but fails to clear VM_MAYWRITE on the resulting read-only mapping. An unprivileged userspace daemon can map the per-queue command buffer with PROT_READ, then upgrade the mapping to PROT_WRITE using mprotect(). This allows corruption of kernel-written struct ublksrv_io_desc ABI fields including addr, op_flags, nr_sectors, and start_sector.

Critical Impact
A local, low-privileged user with access to a ublk character device can corrupt kernel-owned I/O descriptor fields, enabling integrity and availability attacks against block I/O operations.

Affected Products

Linux kernel ublk (userspace block driver) subsystem
Stable trees receiving backports referenced by commits 5befd06, 6e2b571, be41733, e373c1a, and fa5e1bc
Distributions shipping kernels with CONFIG_BLK_DEV_UBLK enabled

Discovery Timeline

2026-09-16 - CVE-2026-89793 published to the National Vulnerability Database (NVD)
2026-09-16 - Last updated in NVD database

Technical Details for CVE-2026-89793

Vulnerability Analysis

The ublk driver exposes a per-queue command buffer to userspace daemons through a character device mmap interface. The command buffer holds struct ublksrv_io_desc entries populated by the kernel to describe pending I/O operations. Userspace is expected to read these descriptors only.

ublk_ch_mmap() enforces read-only semantics by rejecting any mmap() call that carries VM_WRITE. However, the implementation neglects to clear VM_MAYWRITE on the VMA. VM_MAYWRITE controls whether the kernel permits later upgrades via mprotect(). With the flag still set, an unprivileged process can map the buffer PROT_READ, then call mprotect(PROT_READ|PROT_WRITE) and receive a writable mapping backed by kernel memory.

Once writable, the daemon can overwrite addr, op_flags, nr_sectors, and start_sector fields inside io_desc. Because these fields are trusted by the kernel for subsequent block I/O handling, corrupting them undermines the kernel/user trust boundary. The reporter confirmed the write via a mprotect() proof of concept under KASAN. The class of bug mirrors prior fixes in drm/panthor, drm/vc4, and the ptp/vmclock VM_MAYWRITE issue tracked on 2026-08-13.

Root Cause

The root cause is a missing vm_flags_clear(vma, VM_MAYWRITE) call in the ublk_ch_mmap() handler. Rejecting VM_WRITE at mmap time is insufficient because Linux consults VM_MAYWRITE at mprotect() time to decide whether write permission can be granted later.

Attack Vector

Exploitation requires local access with permission to open the ublk character device (typically a user in the ublk daemon role). The attacker opens the device, calls mmap() with PROT_READ, then invokes mprotect() to add PROT_WRITE. Writes to the mapping mutate kernel-owned ublksrv_io_desc fields and influence subsequent kernel block I/O processing. No verified public exploit code is available beyond the reporter's proof of concept described in the commit message.

// No verified public exploit code is available.
// See kernel commits 5befd06, 6e2b571, be41733, e373c1a, and fa5e1bc
// for the authoritative fix and technical context.

Detection Methods for CVE-2026-89793

Indicators of Compromise

Unexpected mprotect() calls that add PROT_WRITE to mappings backed by /dev/ublkc* character devices
Anomalous ublk daemon processes issuing block I/O with mismatched or out-of-range start_sector or nr_sectors values
KASAN or block layer warnings referencing corrupted ublksrv_io_desc fields

Detection Strategies

Audit mprotect() system calls via auditd or eBPF, filtering for target VMAs mapped from ublk character devices
Monitor kernel logs for block subsystem anomalies originating from ublk queues, including invalid descriptor rejections
Inventory hosts with CONFIG_BLK_DEV_UBLK enabled and identify which users can access /dev/ublkc*

Monitoring Recommendations

Enable syscall auditing for mmap, mprotect, and openat targeting ublk device nodes
Ship kernel logs and audit events to a central SIEM for correlation with process lineage
Baseline legitimate ublk daemon behavior and alert on deviations in descriptor field patterns

How to Mitigate CVE-2026-89793

Immediate Actions Required

Apply the upstream kernel fix from the referenced stable commits: 5befd06, 6e2b571, be41733, e373c1a, and fa5e1bc
Restrict access to ublk character devices to trusted service accounts only
If ublk is not required, disable CONFIG_BLK_DEV_UBLK or unload the ublk_drv module

Patch Information

The fix clears VM_MAYWRITE inside ublk_ch_mmap() so that a read-only mapping cannot be upgraded via mprotect(). After the patch, mprotect() attempting to add write permission on the ublk command buffer returns -EACCES. Refer to Kernel Git Commit 5befd06, Kernel Git Commit 6e2b571, Kernel Git Commit be41733, Kernel Git Commit e373c1a, and Kernel Git Commit fa5e1bc for the fix source and backport targets.

Workarounds

Tighten permissions on /dev/ublkc* so only vetted daemon accounts can open the device
Unload the ublk_drv module on systems that do not use userspace block drivers
Apply mandatory access control policies (SELinux or AppArmor) to restrict which processes can call mprotect() on ublk-backed mappings

bash

# Disable ublk on hosts that do not require userspace block drivers
sudo modprobe -r ublk_drv
echo 'blacklist ublk_drv' | sudo tee /etc/modprobe.d/blacklist-ublk.conf

# Restrict device node access to a dedicated group
sudo chown root:ublkops /dev/ublkc*
sudo chmod 0660 /dev/ublkc*