CVE-2026-43014: Linux Kernel MACB Resource Leak Vulnerability

CVE-2026-43014 Overview

CVE-2026-43014 is a resource management flaw in the Linux kernel's Cadence MACB Ethernet driver (drivers/net/ethernet/cadence/macb_main.c). The driver allocates fixed rate clocks via clk_register_fixed_rate() but fails to release them with the corresponding clk_unregister_fixed_rate() call. The unreleased clock structures persist in kernel memory after the driver is unbound, producing a kernel resource leak.

The issue affects systems using MACB-based network interfaces, commonly found in Microchip, Atmel, and Xilinx Zynq SoC platforms. While the flaw does not provide a direct exploitation path, repeated driver bind/unbind cycles can exhaust kernel resources over time.

Critical Impact
Fixed rate clock objects registered by the macb network driver are never unregistered, causing kernel memory and clock framework state to leak on driver removal.

Affected Products

Linux kernel — drivers/net/ethernet/cadence/macb_main.c
Systems using Cadence MACB / GEM Ethernet controllers (Microchip SAMA5, Atmel AT91, Xilinx Zynq)
Embedded Linux distributions shipping the affected MACB driver

Discovery Timeline

2026-05-01 - CVE-2026-43014 published to NVD
2026-05-01 - Last updated in NVD database

Technical Details for CVE-2026-43014

Vulnerability Analysis

The Linux kernel macb driver supports MACB and GEM Ethernet controllers. During probe, the driver may register fixed rate clocks using clk_register_fixed_rate() to expose reference clocks to the clock framework. These registrations allocate struct clk_fixed_rate objects and add entries to the global clock provider list.

The driver previously did not invoke clk_unregister_fixed_rate() on the teardown path. When the driver is unbound, removed via rmmod, or its probe fails after clock registration, the clock objects remain allocated. Memory backing the clock structures is not freed and stale references remain in the kernel's clock framework state.

The upstream fix adds the matching clk_unregister_fixed_rate() calls so that all clocks registered during probe are released during driver removal. Multiple stable branch backports were issued, identifiable by commits 015aa24d, 5392a517, 54c6f0e7, 6ec56742, e1f6f47d, e35dbfdb, ec1be2ce, and f0f367a4.

Root Cause

The root cause is a missing cleanup call. Resources allocated by clk_register_fixed_rate() require an explicit clk_unregister_fixed_rate() to release them. The macb driver violated this lifecycle contract, classifying the flaw as a memory leak [CWE-401] in kernel driver teardown logic.

Attack Vector

The flaw is triggered locally through driver lifecycle operations. A privileged user repeatedly binding and unbinding the macb driver, or environments where probe deferral and retries occur frequently, will accumulate leaked clock objects. The vulnerability does not enable code execution or privilege escalation. The practical impact is gradual kernel resource consumption on long-running systems with frequent driver reload cycles.

No public exploit has been released and the EPSS score is 0.032%, reflecting low expected exploitation activity.

The vulnerability mechanism is described in prose only. See the upstream commits referenced in Kernel Git Commit 015aa24d and Kernel Git Commit f0f367a4 for the exact diff.

Detection Methods for CVE-2026-43014

Indicators of Compromise

Growing kernel slab allocations attributable to clk_fixed_rate objects after repeated macb driver bind/unbind cycles.
Stale entries visible under /sys/kernel/debug/clk/ for clocks that should have been removed with the driver.
Increasing kernel memory usage on embedded devices that periodically reload the macb module.

Detection Strategies

Audit installed kernel versions against the fixed commits listed in the kernel.org stable references to identify unpatched systems.
Use kmemleak on kernel builds with CONFIG_DEBUG_KMEMLEAK=y to detect unreferenced allocations originating from clk_register_fixed_rate call sites.
Compare clock framework state before and after driver unload using cat /sys/kernel/debug/clk/clk_summary to identify clocks not removed at teardown.

Monitoring Recommendations

Track /proc/meminfoSlab and SUnreclaim counters on devices with frequent network driver reloads.
Alert on kernel log messages from the clock framework indicating registration without matching unregistration during module removal.
Inventory embedded Linux fleets using MACB-based NICs and confirm the running kernel includes one of the patch commits.

How to Mitigate CVE-2026-43014

Immediate Actions Required

Update the Linux kernel to a stable release containing the upstream fix for the macb fixed rate clock leak.
Identify embedded and SoC platforms using Cadence MACB Ethernet controllers and prioritize them for kernel update.
Avoid unnecessary bind/unbind cycles of the macb driver on production systems running unpatched kernels.

Patch Information

The fix was merged upstream and backported across multiple stable branches. Apply a kernel build that includes one of the following commits: 015aa24d, 5392a517, 54c6f0e7, 6ec56742, e1f6f47d, e35dbfdb, ec1be2ce, or f0f367a4.

Workarounds

Refrain from unloading and reloading the macb kernel module on unpatched systems to limit accumulation of leaked clocks.
Schedule reboots on long-running embedded systems where kernel updates are not yet available to reclaim leaked resources.
Restrict module management capabilities to administrators only by ensuring CAP_SYS_MODULE is not granted to unprivileged users.

bash

# Verify whether your running kernel includes the fix by checking the changelog
uname -r
zcat /proc/config.gz | grep MACB
# Inspect clock framework state for stale fixed-rate clocks
cat /sys/kernel/debug/clk/clk_summary | grep -i fixed