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

CVE-2026-23305 Overview

A vulnerability has been identified in the Linux kernel's accel/rocket driver involving improper error path handling in the rocket_probe function. When rocket_core_init() fails (such as with EPROBE_DEFER), the driver fails to properly unwind by decrementing the counter that was incremented and, if this is the first core that failed to probe, fails to remove the rocket DRM device with rocket_device_fini(). This improper unwinding results in out-of-bounds memory accesses.

Critical Impact

Improper error path unwinding in the Linux kernel rocket driver can lead to out-of-bounds memory accesses, potentially causing kernel instability, memory corruption, or denial of service conditions.

Affected Products

• Linux kernel with accel/rocket driver enabled
• Systems utilizing DRM acceleration with the rocket driver
• Linux distributions with affected kernel versions

Discovery Timeline

• 2026-03-25 - CVE CVE-2026-23305 published to NVD
• 2026-03-25 - Last updated in NVD database

Technical Details for CVE-2026-23305

Vulnerability Analysis

The vulnerability exists in the rocket_probe function within the Linux kernel's acceleration subsystem (accel/rocket). During device probe operations, a counter is incremented before calling rocket_core_init(). If this initialization function fails—commonly returning EPROBE_DEFER when a required resource is temporarily unavailable—the error handling path does not properly decrement the counter or clean up the DRM device state.

This creates an inconsistent state where the kernel maintains incorrect reference counts and device state information. The mismatch between the actual hardware/resource state and the kernel's internal tracking leads to out-of-bounds array accesses when subsequent operations attempt to reference cores or devices based on the corrupted counter values.

The improper unwinding logic contrasts with the correct cleanup sequence implemented in rocket_remove(), which properly handles counter decrementation and device finalization in the correct order.

Root Cause

The root cause is missing cleanup logic in the error path of the rocket_probe function. When rocket_core_init() fails, the function returns without:

1. Decrementing the core counter that was incremented before the initialization attempt
2. Calling rocket_device_fini() when this is the first core failing to probe, leaving the DRM device in an inconsistent state

This violates the principle that initialization and cleanup paths should be symmetric, leading to resource tracking inconsistencies.

Attack Vector

The vulnerability is triggered when the rocket_core_init() function encounters an error condition during driver probe operations. While the attack vector is not definitively established, the vulnerability could be triggered through:

1. Forcing probe deferral conditions by manipulating resource availability
2. Creating conditions that cause repeated probe failures
3. Exploiting timing windows during driver initialization

The out-of-bounds memory accesses resulting from the corrupted counter state could potentially be leveraged to read or write kernel memory, though exploitation complexity would be high due to the specific conditions required.

Detection Methods for CVE-2026-23305

Indicators of Compromise

• Kernel log messages indicating probe failures or deferrals in the rocket/accel driver
• Unexpected DRM device state or missing devices after probe operations
• Memory corruption warnings or kernel oops related to the rocket driver
• Kernel crash dumps showing out-of-bounds accesses in rocket driver code paths

Detection Strategies

• Monitor kernel logs for rocket_core_init failure messages and EPROBE_DEFER returns
• Implement kernel address sanitizer (KASAN) to detect out-of-bounds memory accesses
• Use kernel debugging tools to track reference counter anomalies in driver subsystems
• Deploy runtime verification tools to monitor driver probe/remove symmetry

Monitoring Recommendations

• Enable enhanced kernel logging for the DRM and acceleration subsystems
• Configure alerting for kernel oops or panics originating from rocket driver components
• Implement automated kernel log analysis for probe failure patterns
• Monitor system stability metrics during driver load/unload operations

How to Mitigate CVE-2026-23305

Immediate Actions Required

• Apply the kernel patches from the official kernel git repository
• Reboot systems after patching to ensure the fix is active
• If the rocket driver is not required, consider blacklisting the module temporarily
• Review and update to a patched kernel version as soon as available from your distribution

Patch Information

The Linux kernel maintainers have released fixes for this vulnerability. The patches ensure proper unwinding in the error path by decrementing the counter and calling rocket_device_fini() when appropriate. The fix aligns the error path behavior with the cleanup logic in rocket_remove().

Patches are available from the following kernel git commits:

• Kernel Git Commit Changes
• Kernel Git Commit Updates
• Kernel Git Commit Fixes

Workarounds

• Blacklist the rocket driver module if not required: add blacklist rocket to /etc/modprobe.d/blacklist.conf
• Disable automatic loading of the accel/rocket driver until patches can be applied
• Use kernel boot parameters to prevent driver loading if applicable
• Monitor systems closely for signs of exploitation until patching is complete

# Configuration example
# Blacklist the rocket driver module
echo "blacklist rocket" >> /etc/modprobe.d/blacklist-rocket.conf

# Prevent module loading for current session
modprobe -r rocket 2>/dev/null || true

# Verify module is not loaded
lsmod | grep rocket

# Update initramfs to persist changes
update-initramfs -u