CVE-2026-43364 Overview
CVE-2026-43364 is a NULL pointer dereference vulnerability [CWE-476] in the Linux kernel's userspace block device (ublk) subsystem. The flaw resides in the ublk_ctrl_set_size() function, which unconditionally dereferences ub->ub_disk through set_capacity_and_notify() without verifying that the pointer is valid. A local user with permission to issue ublk control commands can trigger the dereference by sending a UBLK_CMD_UPDATE_SIZE request to a device that has been added but not yet started, or to one that has already been stopped. The result is a kernel crash and denial of service on the affected host.
Critical Impact
A local attacker can crash the kernel and cause a host-wide denial of service by issuing an UBLK_CMD_UPDATE_SIZE command against a ublk device in an uninitialized or stopped state.
Affected Products
- Linux Kernel 7.0-rc1
- Linux Kernel 7.0-rc2
- Linux Kernel 7.0-rc3
Discovery Timeline
- 2026-05-08 - CVE-2026-43364 published to NVD
- 2026-05-15 - Last updated in NVD database
Technical Details for CVE-2026-43364
Vulnerability Analysis
The ublk driver exposes a control interface that lets userspace manage virtual block devices backed by a userspace daemon. The UBLK_CMD_UPDATE_SIZE handler invokes ublk_ctrl_set_size(), which calls set_capacity_and_notify() on ub->ub_disk without first validating the pointer. The ub->ub_disk field is only populated inside ublk_ctrl_start_dev() after a successful UBLK_CMD_START_DEV. It is cleared back to NULL by ublk_detach_disk() when UBLK_CMD_STOP_DEV runs. Between these two events, or before any start has occurred, the field is NULL.
Because the update-size handler performs no state validation, dereferencing the NULL disk pointer produces an oops in kernel context. The crash terminates the calling task and can leave kernel locks or reference counts in inconsistent states, requiring a reboot to recover. The fix introduced in commits 25966fc0, c28d945b, and f13fe679 adds a check on ub->ub_disk while holding ub->mutex and returns -ENODEV when the disk is not available.
Root Cause
The root cause is missing state validation in the ublk control path. The handler assumes the device has reached the running state without confirming it, violating the lifecycle invariants of the ub_disk field.
Attack Vector
Exploitation requires local access and the ability to open /dev/ublk-control and issue io_uring control commands against a ublk device that the attacker created. The attacker creates a ublk device, then issues UBLK_CMD_UPDATE_SIZE before UBLK_CMD_START_DEV (or after UBLK_CMD_STOP_DEV) to trigger the dereference.
// Vulnerability mechanism (prose description - no verified PoC available)
// 1. Attacker creates a ublk device via UBLK_CMD_ADD_DEV
// 2. ub->ub_disk remains NULL because UBLK_CMD_START_DEV was never issued
// 3. Attacker sends UBLK_CMD_UPDATE_SIZE
// 4. ublk_ctrl_set_size() calls set_capacity_and_notify(ub->ub_disk, ...)
// 5. NULL pointer dereference -> kernel oops -> denial of service
Detection Methods for CVE-2026-43364
Indicators of Compromise
- Kernel oops messages referencing ublk_ctrl_set_size, set_capacity_and_notify, or BUG: kernel NULL pointer dereference in dmesg or /var/log/kern.log.
- Unexpected termination of processes interacting with /dev/ublk-control followed by stale ublk device state.
- io_uring control submissions targeting ublk devices that were never started or that were already stopped.
Detection Strategies
- Monitor kernel ring buffer output for oops signatures that include ublk_ctrl_set_size+ in the call trace.
- Audit openat and ioctl/io_uring_enter activity against /dev/ublk-control from non-root or unexpected workloads.
- Correlate ublk device add events without subsequent start events followed by control commands, which is an atypical lifecycle pattern.
Monitoring Recommendations
- Enable kdump or persistent crash collection so a vmcore is captured when a NULL dereference occurs in the ublk path.
- Forward kernel logs to a central log store and alert on the string ublk_ctrl_set_size appearing alongside Oops or RIP:.
- Track which UIDs and containers have access to ublk control devices and review whether that access is required.
How to Mitigate CVE-2026-43364
Immediate Actions Required
- Apply the upstream stable kernel patches referenced by commits 25966fc097691e5c925ad080f64a2f19c5fd940a, c28d945bfa92e15147e93b73f95345b9bec979b0, and f13fe6794726755a43090cb680c4c58cea6aa5f1.
- Inventory hosts running Linux 7.0-rc1 through 7.0-rc3 and prioritize them for kernel updates.
- Restrict access to /dev/ublk-control to trusted administrative users only.
Patch Information
The fix adds a NULL check on ub->ub_disk while holding ub->mutex in ublk_ctrl_set_size() and returns -ENODEV when the disk is not present. Patches are available from the kernel.org stable tree: Kernel commit 25966fc0, Kernel commit c28d945b, and Kernel commit f13fe679.
Workarounds
- Unload the ublk_drv kernel module on systems that do not require userspace block devices: modprobe -r ublk_drv.
- Blacklist the module so it does not autoload by adding blacklist ublk_drv to /etc/modprobe.d/.
- Tighten permissions on /dev/ublk-control so only privileged service accounts can submit control commands.
# Configuration example: disable ublk on hosts that do not need it
echo 'blacklist ublk_drv' | sudo tee /etc/modprobe.d/disable-ublk.conf
sudo modprobe -r ublk_drv
# Verify the module is no longer loaded
lsmod | grep ublk_drv || echo "ublk_drv not loaded"
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.
