CVE-2026-98564 in Linux
Summary
by MITRE • 10/18/2026
In the Linux kernel, the following vulnerability has been resolved:
net: dsa: mt7530: leave the MDIO IRQ mappings to regmap-irq
mt7530_remove_common() disposes the per-PHY interrupt mappings from .remove, but the regmap-irq chip that owns the domain is devm-registered, so its parent interrupt is only freed once .remove has returned. The switch's own regmap-irq thread can therefore still dispatch on a mapping that is already gone: irq_find_mapping() returns 0, irq_to_desc() returns NULL and handle_nested_irq() locks desc->lock without checking it. The attached PHYs have not given those interrupts back yet either, which the kernel warns about a moment before the fault.
regmap_del_irq_chip() disposes the same mappings itself, after freeing the parent interrupt and before removing the domain, so there is nothing left for the driver to do here. Until it runs the descriptors stay alive, and a late dispatch on one of them is harmless: dsa_unregister_switch() has freed the PHY handlers by then, so handle_nested_irq() finds no action and returns.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 10/19/2026
The vulnerability identified in the Linux kernel's DSA MT7530 driver stems from an improper handling of interrupt resource cleanup during device removal, specifically involving the interaction between per-PHY interrupt mappings and the regmap-irq subsystem. The root cause lies in a race condition within the mt7530_remove_common function, which attempts to dispose of individual PHY interrupt mappings before the parent interrupt domain managed by devm-registers is fully released. Because the regmap-irq chip is registered using device-managed resources, its associated parent interrupt remains active until after the remove callback returns. This timing discrepancy allows a scenario where the switch's internal regmap-irq thread may still attempt to dispatch interrupts on mappings that have already been logically removed from the driver's perspective but are not yet physically freed by the core subsystem.
From a technical standpoint, this misalignment leads to critical null pointer dereferences and potential kernel panics. When irq_find_mapping is called for an interrupt that has been disposed of by the driver but not yet cleaned up by the regmap-irq infrastructure, it returns zero. Subsequently, when irq_to_desc attempts to retrieve the descriptor for this invalid mapping identifier, it returns NULL. The subsequent call to handle_nested_irq proceeds without verifying if the descriptor is valid, attempting to lock desc->lock on a null pointer. This represents a classic use-after-free or race condition vulnerability where software state and hardware interrupt controller state become desynchronized during teardown operations.
The operational impact of this flaw includes system instability, potential denial of service through kernel oops or panic, and unpredictable behavior when network interfaces associated with the MT7530 switch are brought down. Although the patch notes indicate that late dispatches on these descriptors might be harmless because dsa_unregister_switch has already freed PHY handlers by the time handle_nested_irq executes, relying on this implicit safety is risky. The primary risk occurs during the window where the driver believes mappings are gone but the interrupt controller still holds them open, leading to the aforementioned null pointer dereference if an interrupt fires exactly in that interval.
This issue aligns with CWE-416, Use After Free, as it involves accessing memory or resources after they have been made unavailable for use due to improper sequencing of deallocation and access. In terms of MITRE ATT&CK mapping, this vulnerability could be leveraged by an attacker who can trigger network interface removal under specific timing conditions to cause a denial of service against the host system. It falls under techniques related to resource exhaustion or instability exploitation within the operating system layer.
The mitigation implemented in the kernel resolves this by removing the manual disposal of per-PHY interrupt mappings from mt7530_remove_common. Since regmap_del_irq_chip is responsible for disposing these same mappings and operates after freeing the parent interrupt, it ensures a safe cleanup sequence where all references are invalidated before any potential late dispatches occur. This change eliminates the race condition by relying on the correct ordering provided by the devm-registers framework. Administrators should ensure their systems are updated with kernel versions containing this fix to prevent potential instability during network device teardown operations involving MT7530-based switches.