CVE-2026-23295: Linux Kernel Race Condition Vulnerability

CVE-2026-23295 Overview

A deadlock vulnerability has been identified in the Linux kernel's accel/amdxdna driver that affects suspend and resume operations. The flaw occurs when an application issues a query IOCTL while auto suspend is running, causing a circular lock dependency that results in system deadlock.

Critical Impact

Systems running affected Linux kernel versions with AMD XDNA accelerator hardware may experience complete system hangs when IOCTL queries are performed during power management transitions.

Affected Products

• Linux kernel with accel/amdxdna driver
• Systems utilizing AMD XDNA accelerator hardware
• Linux kernel versions with vulnerable power management locking implementation

Discovery Timeline

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

Technical Details for CVE-2026-23295

Vulnerability Analysis

This vulnerability is classified as a Deadlock race condition in the Linux kernel's AMD XDNA accelerator driver. The issue arises from improper lock ordering during power management state transitions.

The query path within the driver holds the dev_lock mutex and then invokes pm_runtime_resume_and_get(), which blocks waiting for any ongoing suspend operation to complete. Simultaneously, the suspend callback attempts to acquire the same dev_lock and blocks because it's already held by the query path. This creates a classic ABBA deadlock scenario where two execution contexts are waiting on resources held by each other.

The vulnerability is particularly dangerous because it can be triggered by normal user-space operations during routine power management activities that occur automatically on modern Linux systems with runtime PM enabled.

Root Cause

The root cause is improper lock acquisition ordering in the accel/amdxdna driver's power management code path. The driver fails to release dev_lock before calling pm_runtime_resume_and_get(), creating a lock dependency cycle between the query IOCTL handler and the suspend callback. Additionally, the resume callback lacked corresponding lock acquisition, leading to inconsistent locking semantics throughout the driver's PM implementation.

Attack Vector

The deadlock can be triggered when:

1. The system initiates auto suspend for the AMD XDNA accelerator device
2. A user-space application concurrently issues a query IOCTL to the driver
3. The query handler acquires dev_lock and attempts runtime resume
4. The suspend callback blocks waiting for dev_lock, while the query handler blocks waiting for suspend completion

This vulnerability primarily represents a Denial of Service condition, as it can cause the system to become unresponsive. The attack vector requires local access and the ability to perform IOCTL operations on the AMDXDNA device, meaning a local user with appropriate permissions could potentially trigger this deadlock, either intentionally or through normal device usage patterns.

Detection Methods for CVE-2026-23295

Indicators of Compromise

• System hangs or freezes occurring during AMD XDNA accelerator operations
• Kernel soft lockup warnings in system logs referencing amdxdna driver functions
• Processes stuck in uninterruptible sleep state (D state) related to XDNA device operations
• Watchdog timer events coinciding with XDNA driver activity

Detection Strategies

• Monitor kernel logs for soft lockup warnings with stack traces involving amdxdna, pm_runtime, or dev_lock
• Implement process monitoring to detect hung processes in D state accessing /dev/accel/ devices
• Configure kernel lockdep debugging to identify lock ordering violations in the AMDXDNA driver
• Review system stability reports for patterns of hangs during power state transitions

Monitoring Recommendations

• Enable CONFIG_PROVE_LOCKING in kernel builds to detect potential deadlock scenarios proactively
• Monitor for hung task warnings via the hung_task_timeout_secs kernel parameter
• Implement automated alerting for system responsiveness degradation on systems with AMD XDNA hardware
• Track kernel runtime PM events for the AMDXDNA driver using ftrace or perf

How to Mitigate CVE-2026-23295

Immediate Actions Required

• Apply the official Linux kernel patches from the stable kernel tree
• Consider disabling runtime power management for the AMDXDNA driver as a temporary workaround
• Monitor systems for signs of deadlock and schedule maintenance windows for patching
• Update to a patched kernel version when available for your distribution

Patch Information

The Linux kernel developers have released patches to address this vulnerability. The fix involves releasing dev_lock before calling pm_runtime_resume_and_get() and reacquiring it after the call completes. The resume callback has also been updated to acquire dev_lock for consistent locking behavior.

Patch commits are available at:

• Linux Kernel Commit 1aa82181a3c285c7351523d587f7981ae4c015c8
• Linux Kernel Commit ac24537478dd8eb2fd3984b4652bb19461e5e74c

Workarounds

• Disable runtime PM for the AMDXDNA device by writing on to /sys/bus/pci/devices/<device>/power/control
• Avoid concurrent IOCTL operations during known power management transitions
• Consider unloading the amdxdna module when not actively needed if feasible for your workload
• Implement application-level serialization of XDNA device access during system power state changes

# Disable runtime power management for AMDXDNA device as workaround
# Find the PCI device ID for your AMD XDNA accelerator first
lspci | grep -i amd

# Disable runtime PM (replace XXXX:XX:XX.X with your device address)
echo 'on' > /sys/bus/pci/devices/XXXX:XX:XX.X/power/control

# Verify runtime PM is disabled
cat /sys/bus/pci/devices/XXXX:XX:XX.X/power/control
# Should output: on