CVE-2026-80743: ASoC: xilinx: formatter_pcm: pass aud_drv_data to irq handlers
In the Linux kernel, the following vulnerability has been resolved:
ASoC: xilinx: formatterpcm: pass auddrvdata to irq handlers
The irq handlers take a struct device pointer and call devgetdrvdata() to obtain the driver data. However, the driver data is only set at the end of probe, after devmrequestirq(), 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 devmrequestirq() argument instead of the device pointer, matching what the handlers expect.
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Configuration
Update the ASoC xilinx formatter_pcm driver so that devm_request_irq() passes the private driver data directly as the devm_request_irq() argument; the irq handlers should receive the struct device pointer they expect, preventing a NULL pointer dereference to readl() and avoiding the crash when an interrupt occurs before dev_get_drvdata() is available.
Linux kernel (ASoC xilinx: formatter_pcm / irq handling) devm_request_irq() argument (private data passed to IRQ handlers) = Pass the private driver data directly to devm_request_irq() instead of passing the device pointer to the IRQ handlers
Event History
Frequently Asked Questions
What systems are exposed to this issue?
Systems using the Linux kernel Xilinx ASoC formatter_pcm driver are exposed during initialization of that driver, when its interrupt handlers have been registered but driver data has not yet been set.
What must happen for the crash to occur?
An interrupt must be taken in the interval after devm_request_irq() registers the handlers and before probe finishes setting the device driver data. The handlers then obtain a NULL driver-data pointer and pass it to readl(), causing a crash.
How can I determine whether a running system has encountered this problem?
The described failure is a kernel crash caused by an interrupt handler passing a NULL pointer to readl() during formatter_pcm driver probe. The provided information does not identify a specific log message or signature beyond that failure path.
What is the mitigation if the fix cannot be applied immediately?
The provided information identifies the vulnerable window as formatter_pcm driver initialization, but does not provide a configuration workaround. Applying the referenced kernel fix changes the IRQ registration to pass the private driver data directly to the handlers.