CVE-2026-72384 in Linux
Summary
by MITRE • 08/15/2026
In the Linux kernel, the following vulnerability has been resolved:
irqchip/ts4800: Fix missing chained handler cleanup on remove
The driver installs a chained handler for the parent interrupt during probe using irq_set_chained_handler_and_data(), but the remove function does not clear this handler. This leaves a dangling handler that may be called when the parent interrupt fires after the driver has been removed, potentially accessing freed memory and causing a kernel crash.
Additionally, the parent_irq obtained via irq_of_parse_and_map() is not stored, making it inaccessible in the remove function. Moreover, interrupt mappings created during probe are not properly disposed.
Fix this by:
- Saving parent_irq in probe - Clearing the chained handler with NULL in ts4800_ic_remove() - Disposing all IRQ mappings before domain removal to prevent resource leaks
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 08/15/2026
This vulnerability exists within the linux kernel's interrupt controller driver for the ts4800 platform, specifically addressing improper cleanup of chained interrupt handlers during driver removal. The flaw stems from a missing step in the driver's remove function that fails to clear the chained handler previously installed during probe phase using irq_set_chained_handler_and_data(). This creates a dangling interrupt handler reference that remains active even after the driver has been unloaded from memory, leading to potential kernel crashes when the parent interrupt fires and attempts to invoke the freed handler.
The technical implementation issue manifests through improper resource management during the driver lifecycle. During driver probe, the ts4800 interrupt controller driver correctly installs a chained handler for the parent interrupt using the standard kernel API irq_set_chained_handler_and_data(), but fails to store the parent_irq value obtained through irq_of_parse_and_map() call. This omission prevents proper cleanup in the remove function since the driver cannot access the original interrupt mapping needed for proper teardown. The absence of storing the parent_irq identifier creates a critical gap in resource tracking that violates standard kernel driver development practices and security principles.
The operational impact of this vulnerability extends beyond simple memory corruption to potentially compromise system stability and availability. When the parent interrupt fires after driver removal, the dangling handler may attempt to access memory that has already been freed or reallocated by the kernel's memory management subsystem. This scenario directly relates to common kernel exploitation patterns where dangling pointers are leveraged for privilege escalation or denial of service attacks. The vulnerability represents a classic case of improper resource cleanup that aligns with CWE-459, which describes "Incomplete Cleanup" in software systems.
The fix implemented addresses multiple aspects of the vulnerability by ensuring proper resource lifecycle management throughout the driver's operation. First, the driver now saves the parent_irq value during probe phase to maintain access to the interrupt mapping for subsequent cleanup operations. Second, the remove function explicitly clears the chained handler by setting it to NULL using the appropriate kernel API, which prevents invocation of freed memory locations. Third, all interrupt mappings created during probe are properly disposed before domain removal, preventing resource leaks that could accumulate over time and eventually lead to system instability or memory exhaustion. This remediation approach follows established kernel development practices and aligns with ATT&CK technique T1068, which involves exploiting local privilege escalation through improper resource handling.
The vulnerability demonstrates how seemingly minor oversights in driver development can create significant security implications within the kernel space. Proper interrupt controller driver implementation requires careful attention to the complete lifecycle of interrupt mappings, including proper cleanup during removal operations. The fix ensures that all interrupt resources are properly managed and released following the principle of least privilege and resource isolation that is fundamental to kernel security architecture. This type of vulnerability highlights the importance of comprehensive testing procedures including stress testing with repeated load/unload cycles to identify resource leak scenarios before deployment in production environments.