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:

1. The del_gendisk() function removes the disk from the system
2. ublk_detach_disk() sets ub->ub_disk to NULL
3. put_disk() potentially frees the disk structure
4. 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:

1. Create a ublk device to trigger the partition scan work scheduling
2. Race the device teardown against the pending partition scan worker
3. 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:

• Kernel Git Commit 72e28774
• Kernel Git Commit f0d385f6

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

# 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