CVE-2026-43014

What it actually does

This flaw is a resource-management bug in the Linux kernel macb Ethernet driver. When the driver registers fixed-rate clocks using clk_register_fixed_rate(), the corresponding resources are not properly released during teardown unless clk_unregister_fixed_rate() is called. On systems using the affected macb driver, repeated initialization and removal paths can leak kernel clock resources. Over time, this can exhaust kernel memory or related clock-framework resources and degrade or disrupt availability. The CVSS vector indicates local access with low privileges is required, no user interaction is needed, and the primary impact is denial of service rather than confidentiality or integrity compromise.

Why it matters to the business

Successful exploitation can cause affected Linux systems to become unstable, lose network functionality, or require rebooting, which may interrupt services hosted on embedded, appliance, industrial, or ARM-based platforms that use the macb/GEM Ethernet driver. The issue is not currently listed in CISA KEV, has low EPSS, and has no known public exploit maturity, so broad internet-scale exploitation is unlikely; however, organizations operating exposed multi-user Linux systems or products using this driver should still patch during normal kernel maintenance because availability impact is high.

How an attack unfolds

An attacker first needs local access to a system where the affected Linux kernel includes and uses the macb Ethernet driver. The attacker then attempts to repeatedly trigger driver probe and teardown paths, such as by causing device bind/unbind cycles, module load/unload cycles where permitted, or repeated device reinitialization. Each cycle can leave fixed-rate clock resources registered instead of being released. As leaked resources accumulate, the kernel may experience memory pressure, clock-framework exhaustion, degraded networking, driver failures, or broader system instability. The practical result is a local denial of service rather than data theft or code execution.

How to fix it

Apply a Linux kernel update from the operating system or device vendor that includes the macb driver fix for properly unregistering fixed-rate clocks during teardown. Where maintaining a custom kernel, backport the upstream change titled "net: macb: properly unregister fixed rate clocks" and verify that every clk_register_fixed_rate() allocation in the macb driver has a matching clk_unregister_fixed_rate() cleanup path. If immediate patching is not possible, reduce exposure by disabling the macb driver where it is not required, preventing unprivileged users from loading/unloading kernel modules, restricting write access to sysfs driver bind/unbind interfaces, limiting local shell access, and monitoring systems for repeated network-driver reset or rebind activity. Because no exact fixed package versions were provided, use vendor advisories and kernel changelogs to identify the first fixed build for each distribution or appliance image.

How to confirm the fix worked

Confirm remediation by verifying the running kernel package or device firmware includes the macb clock-unregister fix from the relevant vendor. On custom kernels, inspect the macb driver source or patch history and confirm clk_unregister_fixed_rate() is used on cleanup/error paths corresponding to clk_register_fixed_rate(). Validate that the running kernel is the updated kernel, not only that the package is installed. On systems using the driver, perform controlled driver initialization and teardown testing in a non-production environment and confirm repeated cycles do not cause increasing kernel memory use, clock-resource growth, macb probe failures, or network instability. Also confirm that unprivileged users cannot write to driver bind/unbind interfaces or load/unload kernel modules unless explicitly required.

Typical attack path

1. Obtain local access to a Linux system running an affected kernel with the macb Ethernet driver present and relevant hardware or platform device support enabled.
2. Identify whether the macb driver can be reloaded, rebound, or otherwise forced through repeated initialization and cleanup paths.
3. Repeatedly trigger driver teardown and reinitialization through available local mechanisms such as module operations, sysfs driver bind/unbind interfaces, or device reset paths.
4. Cause unreleased fixed-rate clock resources to accumulate in the kernel.
5. Exhaust kernel resources or destabilize the network driver, resulting in degraded networking, service disruption, or a system requiring reboot.

How to detect it

To determine whether this was already exploited or triggered, review kernel logs, system journals, audit logs, and endpoint telemetry for repeated macb driver initialization, teardown, reset, bind/unbind, or module load/unload activity followed by memory pressure, network interface failures, or reboots. Useful log sources include journald, dmesg, kern.log, syslog, auditd records for writes to sysfs driver control files, command histories where available, EDR process telemetry, and kernel OOM or panic logs. Look for repeated access to platform driver bind/unbind paths, repeated modprobe/rmmod operations involving macb, unexpected network interface flapping, macb probe failures, clock registration errors, and availability events that correlate with local user activity. There are no known actor-specific or malware-specific indicators for this vulnerability, so detection should focus on behavioral patterns rather than static exploit signatures.

• macb
• macb:
• /sys/bus/platform/drivers/macb/bind
• /sys/bus/platform/drivers/macb/unbind
• /sys/module/macb
• modprobe macb
• rmmod macb
• insmod macb
• clk_register_fixed_rate
• clk_unregister_fixed_rate
• fixed-rate clock
• Out of memory
• oom-killer
• Kernel panic
• NETDEV WATCHDOG

What your security team should do

• Prioritize patching systems that use Cadence MACB/GEM Ethernet hardware, embedded Linux images, appliances, or ARM-based platforms where the macb driver is enabled.
• Treat this primarily as a local availability risk: focus first on shared, multi-user, lab, development, appliance, and edge systems where local users or processes can trigger driver lifecycle operations.
• Inventory kernels with CONFIG_MACB or the macb driver module present, then determine whether the driver is actually loaded or required.
• Apply vendor kernel or firmware updates that include the macb fixed-rate clock cleanup patch; for custom kernels, backport and rebuild the driver or kernel.
• Restrict kernel module management and sysfs driver bind/unbind permissions to trusted administrators only.
• Add monitoring for repeated macb driver bind/unbind, module load/unload, device reset, kernel memory pressure, and unexpected network interface flapping.
• Because EPSS is low, KEV is false, and no public exploit maturity is reported, schedule remediation according to normal availability-risk patch cycles unless the system is safety-critical, operationally sensitive, or allows local untrusted users.