CVE-2026-43372

What it actually does

This flaw is an availability issue in the Linux kernel Microchip DSA switch driver PTP interrupt setup path. When PTP message IRQ setup creates an IRQ mapping and request_threaded_irq() then fails, the driver error path does not dispose of the newly created mapping. Repeatedly reaching this failure path can leak IRQ mappings and related kernel resources, potentially causing interrupt allocation failures, driver malfunction, degraded networking behavior, or a kernel-level denial of service. The issue is local in nature, requires low privileges according to the CVSS vector, does not require user interaction, and does not directly provide confidentiality or integrity impact.

Why it matters to the business

Systems that rely on Linux kernels with Microchip KSZ/DSA switch hardware and PTP functionality could experience network disruption, device instability, or outages if the vulnerable path is repeatedly triggered. The practical exposure is narrower than internet-facing remote-code-execution issues because exploitation requires local access and specific hardware/driver conditions, and the CVE is not in CISA KEV, has no known mature exploit, and has a very low EPSS score. However, for embedded systems, industrial devices, appliances, or network equipment where uptime is critical, a kernel-level denial of service can still create operational downtime and require manual recovery or reboot.

How an attack unfolds

An attacker first needs local access to a vulnerable Linux system where the Microchip DSA switch driver and PTP IRQ setup path are present and reachable. The attacker then attempts to trigger PTP interrupt setup under conditions where request_threaded_irq() fails after an IRQ mapping has already been created. Because the error path does not clean up that mapping, each failed setup can leave behind kernel IRQ mapping state. By repeatedly exercising the failing setup path, the attacker may exhaust or degrade IRQ-related resources, causing later driver initialization or interrupt registration to fail. The end result is a denial-of-service condition affecting kernel stability or network device availability rather than code execution or data theft.

How to fix it

Apply a Linux kernel update from the operating system, appliance, or device vendor that includes the fix for the Microchip DSA PTP IRQ setup error path. Because no fixed versions were provided in the input, use vendor advisories, distribution changelogs, or upstream stable kernel release notes to identify the first fixed kernel for the platform. Reboot into the updated kernel after installation. Where immediate patching is not possible, reduce exposure by disabling unused Microchip KSZ DSA/PTP functionality, unloading or blacklisting the affected driver only if operationally safe, restricting local shell access, limiting users with network administration capabilities, and monitoring for repeated driver initialization failures. For embedded or appliance deployments, obtain firmware updates from the device vendor rather than applying an unrelated generic kernel build.

How to confirm the fix worked

Confirm remediation by verifying that the running kernel version, vendor kernel package, or appliance firmware includes the upstream fix that disposes the IRQ mapping when request_threaded_irq() fails in ksz_ptp_irq_setup(). Check the active kernel with uname -a and package-manager metadata, then compare against the vendor’s fixed release notes. If source or debug symbols are available, confirm the Microchip DSA PTP IRQ setup error path calls the appropriate IRQ mapping disposal routine on request_threaded_irq() failure. Validate exposure by checking whether the system uses affected Microchip KSZ/DSA switch support, whether the relevant kernel module or built-in driver is present, and whether PTP support is enabled. After patching and rebooting, review dmesg or journal logs for continued IRQ allocation failures, Microchip DSA driver errors, or repeated network-device initialization failures.

Typical attack path

1. Obtain local access to a Linux system using an affected kernel and Microchip KSZ/DSA switch functionality.
2. Identify that the vulnerable Microchip DSA/PTP driver path is loaded or available.
3. Trigger PTP IRQ setup or related device initialization paths that call request_threaded_irq().
4. Force or induce request_threaded_irq() failure after an IRQ mapping has been created.
5. Repeat the sequence so undisposed IRQ mappings accumulate.
6. Cause IRQ allocation failures, driver malfunction, degraded network behavior, or a kernel denial of service.

How to detect it

There are no known public exploitation campaigns, no KEV listing, and no reliable network indicators for this local denial-of-service issue. To determine whether exploitation or attempted triggering occurred, review kernel and system logs such as dmesg, journalctl -k, /var/log/kern.log, and /var/log/syslog for repeated Microchip DSA, KSZ, PTP, IRQ mapping, or threaded IRQ registration failures followed by network interface resets, driver probe failures, hangs, watchdog events, or unexpected reboots. Correlate those events with local user activity from auditd, sudo logs, shell history where available, and process accounting, especially commands or services that repeatedly bring interfaces up and down, reload network drivers, or manipulate PTP/network timing configuration. Also check uptime and crash dump records for repeated kernel instability. Because the bug manifests as resource leakage in an error path, evidence may look like recurring setup failures and increasing instability rather than a distinctive exploit signature.

What your security team should do

• Prioritize patching for embedded, appliance, industrial, or network-device deployments that use Linux with Microchip KSZ/DSA switch hardware and require high availability.
• Verify whether the affected driver path is present and in use before assigning emergency priority to general-purpose Linux hosts.
• Apply vendor kernel or firmware updates and reboot into the fixed kernel; do not rely on package installation alone if the old kernel remains running.
• Restrict local access and network-administration privileges on affected systems until patched.
• If PTP or Microchip KSZ switch functionality is not required, consider disabling it as a temporary mitigation after operational testing.
• Monitor kernel logs for repeated IRQ allocation failures, Microchip DSA/PTP setup errors, unexpected interface resets, hangs, or reboots.
• Treat this as an availability-risk vulnerability rather than a data-exfiltration or remote-compromise issue unless paired with another local-access vulnerability.