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

CVE-2026-23162 Overview

A double-free vulnerability has been identified in the Linux kernel's drm/xe/nvm module. The flaw occurs during auxiliary device initialization failure handling, where memory associated with the NVM auxiliary device can be freed twice, leading to kernel memory corruption.

The vulnerability manifests when auxiliary_device_add() fails after a successful auxiliary_device_init() call. In this scenario, the driver calls auxiliary_device_uninit(), which triggers put_device() and subsequently the .release callback (xe_nvm_release_dev()), freeing the NVM structure. However, the original error handling path also attempted to free the same memory via kfree(nvm), resulting in a double-free condition.

Critical Impact

Kernel memory corruption via double-free can lead to system instability, denial of service, or potentially local privilege escalation on affected Linux systems using Intel Xe graphics drivers.

Affected Products

• Linux kernel with drm/xe graphics driver module
• Systems running kernel version 6.19.0-rc2 and related development branches
• Intel Xe graphics hardware with NVM subsystem support

Discovery Timeline

• 2026-02-14 - CVE CVE-2026-23162 published to NVD
• 2026-02-18 - Last updated in NVD database

Technical Details for CVE-2026-23162

Vulnerability Analysis

This double-free vulnerability occurs in the xe_nvm_init() function within the Intel Xe graphics driver's NVM (Non-Volatile Memory) subsystem. The root cause lies in improper error handling during auxiliary device registration.

When initializing an auxiliary device, the Linux kernel auxiliary bus framework requires a specific sequence: auxiliary_device_init() followed by auxiliary_device_add(). If auxiliary_device_init() succeeds, the aux_dev->dev.release callback (set to xe_nvm_release_dev()) becomes responsible for memory cleanup via auxiliary_device_uninit().

The vulnerable code path incorrectly included a kfree(nvm) call in the error handling path after auxiliary_device_add() failure. Since auxiliary_device_uninit() already triggers the release callback that frees the NVM structure, this results in the same memory being freed twice.

KASAN (Kernel Address Sanitizer) detected this double-free condition during testing, as shown in the kernel logs indicating the bug at xe_nvm_init+0x751/0xf10.

Root Cause

The vulnerability stems from incorrect memory ownership semantics in the error handling path. After auxiliary_device_init() succeeds, ownership of the memory transfers to the auxiliary device framework, and only the .release callback should free it. The original code violated this ownership model by retaining an explicit kfree() in the error path, creating the double-free condition.

Attack Vector

This vulnerability requires local access to a system with Intel Xe graphics hardware and the xe driver loaded. While exploitation requires triggering the specific error condition during NVM auxiliary device initialization, a local attacker with sufficient privileges to interact with the graphics subsystem could potentially:

1. Trigger the auxiliary_device_add() failure condition through resource exhaustion or specific driver interactions
2. Exploit the resulting double-free to corrupt kernel memory structures
3. Potentially achieve local privilege escalation or cause denial of service

The attack complexity is considered high as it requires precise timing and control over kernel memory allocation patterns. The vulnerability affects kernel memory, making exploitation difficult but not impossible for sophisticated attackers.

Detection Methods for CVE-2026-23162

Indicators of Compromise

• KASAN reports in kernel logs indicating double-free at xe_nvm_init function offset
• Kernel panic or oops messages referencing the xe driver module during device initialization
• Unexpected system crashes when Intel Xe graphics devices are being initialized
• Memory corruption warnings in dmesg related to the drm/xe subsystem

Detection Strategies

• Enable KASAN (Kernel Address Sanitizer) in kernel builds to detect double-free conditions at runtime
• Monitor kernel logs (dmesg) for auxiliary device initialization failures in the xe driver
• Deploy kernel tracing on xe_nvm_init and related functions to detect anomalous error paths
• Use SentinelOne Singularity platform to detect kernel memory corruption patterns and anomalous driver behavior

Monitoring Recommendations

• Configure syslog monitoring for KASAN and KFENCE kernel memory debugging reports
• Implement alerting on repeated xe driver initialization failures
• Enable kernel function tracing for the xe_nvm_init and auxiliary_device_uninit functions during incident investigation
• Monitor for unusual patterns of driver load/unload cycles that could indicate exploitation attempts

How to Mitigate CVE-2026-23162

Immediate Actions Required

• Apply kernel patches from the stable kernel tree immediately on systems using Intel Xe graphics
• If patching is not immediately possible, consider temporarily disabling or blacklisting the xe kernel module
• Monitor affected systems for signs of exploitation attempts or system instability
• Ensure KASAN or KFENCE is enabled in development/testing environments to detect similar issues

Patch Information

The fix has been applied to the stable Linux kernel tree. The patch moves the kfree(nvm) call to only execute in the auxiliary_device_init() failure path and removes it from the error goto path after successful initialization. This ensures proper memory ownership semantics are maintained.

Two kernel commits address this vulnerability:

• Kernel Commit Update - commit 32887d8e4bc0696b3cb6c5915a42b39cfd3434f4
• Kernel Commit Change - commit 8a44241b0b83a6047c5448da1fff03fcc29496b5

The original fix was cherry-picked from commit a3187c0c2bbd947ffff97f90d077ac88f9c2a215.

Workarounds

• Blacklist the xe kernel module by adding blacklist xe to /etc/modprobe.d/blacklist.conf if the Intel Xe graphics driver is not required
• Use an alternative graphics driver if available for your hardware configuration
• Restrict local user access on systems with Intel Xe graphics until patches can be applied
• Deploy kernel live patching solutions if available for your distribution to apply fixes without reboot

# Configuration example
# Temporarily blacklist the xe module until patched kernel is available
echo "blacklist xe" | sudo tee /etc/modprobe.d/blacklist-xe.conf

# Prevent module loading at runtime
sudo modprobe -r xe 2>/dev/null || echo "Module not loaded or in use"

# Verify module is not loaded
lsmod | grep xe