CVE-2026-23469: Linux Kernel Race Condition Vulnerability

CVE-2026-23469 Overview

A race condition vulnerability exists in the Linux kernel's drm/imagination GPU driver where the runtime power management (PM) suspend callback fails to synchronize with interrupt handlers running on other CPU cores. This oversight can result in the IRQ handler attempting to access GPU registers after the GPU has been suspended, leading to kernel panics and system crashes.

The vulnerability occurs because the suspend callback does not call synchronize_irq() before proceeding with the power-off sequence, allowing concurrent execution of the IRQ handler while GPU resources are being disabled.

Critical Impact

This vulnerability can cause kernel panics and system crashes when the GPU IRQ handler runs concurrently with a runtime PM suspend operation, potentially leading to denial of service on affected systems.

Affected Products

• Linux kernel with drm/imagination GPU driver
• Systems using PowerVR GPU with runtime PM enabled
• Texas Instruments AM68 SK and similar embedded platforms

Discovery Timeline

• 2026-04-03 - CVE CVE-2026-23469 published to NVD
• 2026-04-07 - Last updated in NVD database

Technical Details for CVE-2026-23469

Vulnerability Analysis

This vulnerability represents a classic race condition in the Linux kernel's power management subsystem for the Imagination Technologies GPU driver. The core issue lies in the runtime PM suspend callback's failure to ensure that all interrupt handlers have completed execution before initiating the GPU power-off sequence.

When the system decides to suspend the GPU to save power, it invokes the runtime PM suspend callback. However, this callback does not check whether the IRQ handler (pvr_device_irq_thread_handler) is currently executing on another CPU core. If an interrupt was serviced just before or during the suspend operation, the threaded IRQ handler may continue to run and attempt to access GPU registers through functions like pvr_riscv_irq_pending().

Since the GPU is in the process of being powered down or already suspended, these register accesses result in an asynchronous SError interrupt on ARM64 platforms, causing a kernel panic with error code 0x00000000bf000000.

Root Cause

The root cause is twofold:

1. Missing synchronization barrier: The runtime PM suspend callback does not call synchronize_irq() to wait for any in-progress IRQ handlers to complete before proceeding with the power-off sequence.

2. Improper PM resume/put placement: The driver had runtime PM resume and put calls placed inside the threaded IRQ handler, which was both incorrect in approach and positioned improperly (not wrapping all GPU register accesses). This design could also lead to deadlocks between synchronize_irq() called from the suspend callback (holding the device power lock) and the resume callback requiring the same lock.

Attack Vector

This vulnerability is triggered through local system conditions rather than external attack vectors. The race condition manifests under the following circumstances:

The exploitation scenario involves timing-dependent behavior where an interrupt is generated by the GPU just as the runtime PM subsystem initiates a suspend operation. The IRQ handler is dispatched to a different CPU core than the one executing the suspend callback. Without proper synchronization, both operations proceed concurrently.

On ARM64 platforms like the Texas Instruments AM68 SK, attempting to read GPU registers after the device is suspended generates an asynchronous SError interrupt. The kernel's error handling routine then triggers a panic, as the crash signature demonstrates with the call trace showing pvr_riscv_irq_pending+0xc/0x24 being executed when the error occurs.

While this is not a remotely exploitable vulnerability, a local attacker with the ability to influence GPU workloads and system power management policies could potentially trigger denial of service conditions on affected systems.

Detection Methods for CVE-2026-23469

Indicators of Compromise

• Kernel panic messages containing SError Interrupt with code 0x00000000bf000000
• Stack traces showing pvr_riscv_irq_pending or pvr_device_irq_thread_handler in the call path
• System crashes coinciding with GPU suspend/resume cycles
• irq/234-gpu or similar GPU IRQ thread names in panic logs

Detection Strategies

• Monitor kernel logs for SError interrupts originating from the drm/imagination driver components
• Implement kernel oops/panic monitoring to capture stack traces involving pvr_* functions during power management operations
• Deploy system stability monitoring to detect unexpected reboots correlating with GPU idle periods
• Use ftrace or perf to trace runtime PM callbacks and IRQ handler execution timing

Monitoring Recommendations

• Enable kernel crash dump collection (kdump) to capture full diagnostic information when panics occur
• Configure persistent logging to preserve kernel messages across reboots
• Monitor for MACHINE_CHECK taint flags ([M]) in kernel logs which indicate hardware-related errors
• Set up alerting for GPU driver-related errors in dmesg output

How to Mitigate CVE-2026-23469

Immediate Actions Required

• Apply the kernel patches from the stable branch immediately on affected systems
• Consider disabling runtime PM for the drm/imagination driver as a temporary workaround if patching is not immediately possible
• Monitor systems for stability issues and kernel panics until patches are applied
• Review system logs for any evidence of exploitation or impact from this vulnerability

Patch Information

The Linux kernel developers have released patches to address this vulnerability. The fix adds a call to synchronize_irq() in the power-off sequence to ensure any IRQ handlers in progress on other CPU cores complete before proceeding with GPU suspension. Additionally, the improper runtime PM resume/put calls within the threaded IRQ handler have been removed.

The patches are available through the following kernel git commits:

• Kernel Git Commit 2d7f05c
• Kernel Git Commit 772f365
• Kernel Git Commit 8e0c15e

Workarounds

• Disable runtime power management for the GPU by setting the appropriate sysfs parameters under /sys/devices/.../power/control to on
• Reduce GPU workload variability to minimize suspend/resume frequency
• Pin GPU-related IRQ handlers to specific CPU cores to reduce race condition timing windows
• Consider kernel parameter adjustments to increase PM autosuspend delay, reducing the frequency of suspend operations

# Disable runtime PM for the GPU device (temporary workaround)
echo "on" > /sys/class/drm/card0/device/power/control

# Increase autosuspend delay to reduce suspend frequency (alternative workaround)
echo 60000 > /sys/class/drm/card0/device/power/autosuspend_delay_ms