CVE-2026-80743 in Linux
Summary
by MITRE • 09/03/2026
In the Linux kernel, the following vulnerability has been resolved:
ASoC: xilinx: formatter_pcm: pass aud_drv_data to irq handlers
The irq handlers take a struct device pointer and call dev_get_drvdata() to obtain the driver data. However, the driver data is only set at the end of probe, after devm_request_irq(), so an interrupt taken in between causes the handlers to pass a NULL pointer to readl() and crash.
Pass the private data directly as the devm_request_irq() argument instead of the device pointer, matching what the handlers expect.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 09/03/2026
The Linux kernel audio subsystem contains a race condition vulnerability within the Xilinx ASoC formatter PCM driver that can lead to a system crash due to improper handling of interrupt context data during initialization. This flaw stems from an incorrect association between the device structure and the private driver data when registering hardware interrupts. Specifically, the irq handlers are implemented to accept a struct device pointer as their argument and subsequently invoke dev_get_drvdata() to retrieve the actual driver-specific state information required for operation. However, in the probe function responsible for initializing the driver, the call to devm_request_irq() is executed before the private data structure is fully initialized and associated with the device via dev_set_drvdata(). This sequencing error creates a critical window of vulnerability where an interrupt triggered by hardware activity between the registration of the IRQ handler and the assignment of driver data will cause the handler to receive a valid device pointer but retrieve NULL for its internal state.
When such an early-occurring interrupt is processed, the irq handler attempts to dereference this NULL pointer during readl() operations intended to access audio controller registers. This null pointer dereference results in a kernel panic or system crash, effectively causing a denial of service condition. The vulnerability highlights a common pitfall in Linux driver development where resource allocation and initialization steps are not strictly ordered relative to interrupt enablement. By passing the device structure instead of the private data directly, the code relies on dev_get_drvdata() which returns NULL if called prematurely. This architectural mismatch between what is passed to the request function and what the handler expects creates a fragile state that breaks under normal hardware timing variations during boot or runtime initialization phases.
From a classification perspective, this vulnerability aligns with CWE-476, Null Pointer Dereference, as the core issue involves accessing memory through an uninitialized pointer leading to undefined behavior and system instability. It also relates to CWE-362, Concurrent Execution using Shared Resource with Improper Synchronization, specifically regarding race conditions during resource initialization where timing dependencies are not properly managed. In terms of ATT&CK mapping, this represents a potential entry point for local denial-of-service attacks if an attacker can trigger hardware interrupts at precise moments during driver loading or reconfiguration, although it is primarily exploitable through physical access or privileged software triggering specific audio events rather than remote exploitation.
To mitigate this vulnerability, the fix involves modifying the devm_request_irq() call to pass the private data structure directly as the argument instead of the device pointer. This change ensures that when the irq handler executes, it receives a valid reference to its own state immediately upon invocation, eliminating the dependency on dev_get_drvdata(). Developers should adhere to strict initialization sequences in kernel drivers by ensuring all necessary driver-specific structures are allocated and associated with devices before enabling any hardware interrupts or registering handlers that depend on those structures. This approach prevents race conditions during the critical probe phase and ensures robust handling of asynchronous events regardless of timing variations in interrupt delivery.