CVE-2026-22995: Linux Kernel Use-After-Free Vulnerability

CVE-2026-22995 Overview

A use-after-free vulnerability has been identified in the Linux kernel's ublk (userspace block device) subsystem. The vulnerability exists within the ublk_partition_scan_work function, where a race condition between asynchronous partition scan work and device teardown can lead to dangerous memory access after the disk object has been freed.

Critical Impact
This use-after-free vulnerability in the Linux kernel ublk subsystem could potentially allow local attackers to cause system instability, crashes, or potentially execute arbitrary code with kernel privileges through exploitation of the race condition.

Affected Products

Linux kernel versions with ublk subsystem support
Systems utilizing userspace block devices (ublk)
Linux distributions running affected kernel versions

Discovery Timeline

2026-01-23 - CVE CVE-2026-22995 published to NVD
2026-01-26 - Last updated in NVD database

Technical Details for CVE-2026-22995

Vulnerability Analysis

This vulnerability is classified as a Use-After-Free (UAF) condition stemming from improper synchronization between concurrent kernel operations. The flaw occurs in the ublk block device driver, which provides userspace block device functionality in the Linux kernel.

The race condition manifests during the interaction between device initialization and teardown sequences. When a ublk device is started via ublk_ctrl_start_dev(), partition scanning work is scheduled asynchronously after add_disk() completes. However, if device teardown via ublk_stop_dev() occurs concurrently, the following dangerous sequence can unfold:

The del_gendisk() function removes the disk from the system
ublk_detach_disk() sets ub->ub_disk to NULL
put_disk() potentially frees the disk structure
The partition scan worker then attempts to dereference ub->ub_disk, accessing freed memory

This type of race condition vulnerability can lead to memory corruption, kernel panics, or in worst-case scenarios, privilege escalation if an attacker can control the contents of the freed memory region.

Root Cause

The root cause is the lack of proper reference counting and synchronization between the asynchronous partition scan worker (ublk_partition_scan_work) and the device teardown path. The original implementation did not hold a reference to the disk object during the partition scan operation, allowing the teardown sequence to free the disk while the worker was still pending or executing.

Additionally, the use of flush_work() instead of cancel_work_sync() meant the partition scan work could still run even after the disk had been detached, further contributing to the race condition.

Attack Vector

The attack vector requires local access to the system with the ability to create and manipulate ublk devices. An attacker would need to:

Create a ublk device to trigger the partition scan work scheduling
Race the device teardown against the pending partition scan worker
Potentially manipulate memory allocations to control what data occupies the freed disk structure

While exploitation requires local access and specific timing conditions, the kernel-level nature of the vulnerability makes successful exploitation particularly dangerous.

The fix introduces proper reference counting through ublk_get_disk() and ublk_put_disk() functions in the worker, with spinlock synchronization against ublk_detach_disk(). This ensures the worker either obtains a valid reference or exits early if the disk is already detached. The change from flush_work() to cancel_work_sync() prevents unnecessary execution of partition scan work when the disk is already being torn down.

Detection Methods for CVE-2026-22995

Indicators of Compromise

Kernel oops or panic messages referencing ublk_partition_scan_work or related ublk functions
System crashes during ublk device creation or destruction operations
Unusual kernel memory access violations in block device subsystem
Kernel log entries showing null pointer dereferences in ublk code paths

Detection Strategies

Monitor kernel logs for ublk-related crash reports or warnings using tools like dmesg or journalctl
Deploy kernel crash dump analysis to identify use-after-free patterns in ublk subsystem
Implement runtime memory debugging tools such as KASAN (Kernel Address Sanitizer) to detect UAF conditions
Audit systems for ublk device usage and assess exposure to this vulnerability

Monitoring Recommendations

Configure kernel crash reporting (kdump/kexec) to capture crash dumps for forensic analysis
Enable kernel tracing for block device operations to identify suspicious ublk activity
Monitor system stability metrics for unexpected reboots or kernel panics
Review kernel audit logs for ublk device creation and teardown patterns

How to Mitigate CVE-2026-22995

Immediate Actions Required

Update the Linux kernel to a patched version containing the fix commits
If patching is not immediately possible, consider disabling ublk module loading via kernel module blacklisting
Restrict access to ublk device creation to trusted users only
Monitor systems for signs of exploitation attempts or instability

Patch Information

The vulnerability has been addressed in the Linux kernel stable tree. The fix introduces proper reference counting using ublk_get_disk() and ublk_put_disk() functions in the partition scan worker, along with spinlock synchronization to safely coordinate with ublk_detach_disk(). The patch also changes flush_work() to cancel_work_sync() to prevent unnecessary work execution during device detachment.

Patches are available from the following kernel git commits:

Workarounds

Blacklist the ublk kernel module if not required: add blacklist ublk_drv to /etc/modprobe.d/blacklist.conf
Restrict ublk device operations to essential services only
Limit user access to ublk-related system calls through seccomp or similar sandboxing mechanisms
Monitor and control ublk device lifecycle through administrative policies

bash

# Configuration example
# Blacklist ublk module if not needed
echo "blacklist ublk_drv" >> /etc/modprobe.d/blacklist-ublk.conf

# Unload module if currently loaded
modprobe -r ublk_drv

# Verify module is not loaded
lsmod | grep ublk