CVE-2026-43219

What it actually does

This vulnerability is a Linux kernel availability flaw in the cpsw_new Ethernet driver error-handling path. If registration of a CPSW network device fails during port initialization, the driver can later attempt to unregister a network device that was never successfully registered. That invalid unregister operation can trigger a kernel warning, crash, panic, or other instability, resulting in a local denial of service. The issue requires local privileges and affects systems using the relevant CPSW Ethernet driver path, commonly associated with embedded or SoC-based Linux platforms rather than all general-purpose Linux deployments.

Why it matters to the business

Successful exploitation can crash or destabilize affected Linux systems, causing loss of network connectivity, device outages, or full system reboots. The practical business risk is highest for embedded, industrial, appliance, edge, or IoT systems that rely on CPSW Ethernet interfaces and where unplanned downtime affects operations. The CVSS score is moderate, EPSS is very low and stable, it is not listed in CISA KEV, and there is no known exploit maturity, so this should generally be handled through normal kernel maintenance unless affected devices are operationally critical.

How an attack unfolds

An attacker must already have local access with sufficient privilege to influence network driver initialization or trigger conditions that cause register_netdev() to fail for the first CPSW MAC during cpsw_register_ports(). When that error path is reached, stale state for another CPSW network device may remain. During cleanup, cpsw_unregister_ports() can attempt to unregister a netdev object that was not actually registered. Because unregister_netdev() is not safe for an unregistered device, the kernel may hit an invalid state and crash or panic. Exploitation is therefore not a typical remote network attack; it depends on local access and the ability to trigger the affected driver lifecycle or fault condition.

How to fix it

Upgrade to a Linux kernel version from the relevant distribution, device vendor, or upstream stable branch that includes the cpsw_new fix adding a netdev registration-state check before unregister_netdev() is called. Because no exact fixed package versions were provided, use vendor advisories and kernel changelogs to identify the first fixed release for each supported platform. Where immediate patching is not possible, reduce exposure by limiting local shell access, restricting administrative capabilities that can manipulate network interfaces or drivers, preventing untrusted users from loading or unloading kernel modules, and disabling unused CPSW interfaces or the affected driver on systems that do not require it. For embedded products, obtain updated firmware or BSP/kernel images from the hardware or OS vendor.

How to confirm the fix worked

Confirm that the running kernel or vendor firmware contains the cpsw_new change that checks ndev->reg_state before calling unregister_netdev(). Validate by reviewing the kernel package changelog, vendor advisory, or source tree for the cpsw_unregister_ports() fix. On running systems, confirm the active kernel with uname -a and compare it to the vendor-fixed release. Verify whether the affected driver is present or active by checking loaded modules, kernel configuration, device tree/platform configuration, and network interfaces associated with CPSW hardware. After patching, perform controlled reboot and network interface initialization testing on representative hardware and confirm there are no kernel oops, panic, or cpsw-related unregister_netdev warnings in kernel logs.

Typical attack path

1. Gain local access to an affected Linux system with the vulnerable cpsw_new driver present and in use.
2. Obtain sufficient privileges to manipulate network device state, driver binding, module loading, device initialization, or related platform configuration.
3. Trigger a CPSW port registration failure during register_netdev(), particularly for the first MAC in cpsw_register_ports().
4. Cause the driver cleanup path to execute cpsw_unregister_ports().
5. The cleanup path attempts to unregister a netdev that was not successfully registered.
6. The kernel enters an invalid state, potentially producing an oops, panic, reboot, or loss of network availability.

How to detect it

Detection should focus on evidence of kernel instability around CPSW Ethernet driver initialization and cleanup. Review kernel logs from journalctl, dmesg, /var/log/kern.log, /var/log/messages, crash dumps, pstore, netconsole, serial console captures, and device watchdog or reboot telemetry. Look for crashes, oops traces, warnings, or panics that mention cpsw_new, cpsw_register_ports, cpsw_unregister_ports, register_netdev, unregister_netdev, or net_device registration state. Correlate these events with local administrative activity such as driver bind/unbind operations, module load/unload attempts, network interface resets, firmware updates, device tree changes, or scripted network reconfiguration. Because exploitation requires local access and no public exploit is known, absence of these crash artifacts is a strong indicator that the vulnerability has not been exercised, though log loss after a panic may limit confidence.

• cpsw_unregister_ports
• cpsw_register_ports
• cpsw_new
• register_netdev
• unregister_netdev
• unregister_netdevice: waiting for
• kernel BUG
• kernel panic
• Oops:
• WARNING: CPU:
• Unable to handle kernel NULL pointer dereference
• Internal error: Oops
• net_device
• reg_state

What your security team should do

• Prioritize patching on embedded, appliance, industrial, edge, or SoC-based Linux systems that use CPSW Ethernet hardware and have high availability requirements.
• Track vendor kernel, BSP, firmware, or distribution advisories for the exact fixed version applicable to each affected product line.
• Restrict local interactive access and administrative privileges on systems that cannot be patched quickly.
• Prevent untrusted users from loading, unloading, rebinding, or otherwise manipulating kernel drivers and network interfaces.
• Monitor kernel logs for cpsw_new, cpsw_unregister_ports(), register_netdev(), unregister_netdev(), kernel oops, panic, or unexpected reboot events.
• Include this issue in routine kernel maintenance rather than emergency response unless affected devices are safety-critical, internet-exposed for management, or known to allow local multi-user access.
• Test patches on representative hardware before broad rollout, because network-driver fixes can affect boot-time interface availability on embedded platforms.