CVE-2026-43015

What it actually does

This is a Linux kernel use-after-free in the MACB Ethernet driver PCI glue removal path. During removal of the macb_pci driver or associated platform device, clock objects can be unregistered and freed while later runtime power-management resume logic still dereferences them through clk_prepare(). That stale pointer access can corrupt kernel memory or crash the system. Because the bug occurs in kernel context, successful exploitation could potentially affect confidentiality, integrity, and availability of the host, although exploitation requires local access and the ability to trigger the vulnerable driver/device removal path.

Why it matters to the business

Affected Linux systems using the MACB PCI Ethernet driver may be exposed to local denial-of-service or, in a worst case, local privilege escalation through kernel memory corruption. The highest operational concern is unplanned host crashes or instability during module unload, device removal, driver reload, hardware hotplug, or maintenance workflows. EPSS is very low and there is no known CISA KEV listing or ransomware association, so this should be prioritized based on whether the affected driver is present and reachable in production rather than treated as an internet-scale emergency.

How an attack unfolds

An attacker first needs local access to a system where the vulnerable Linux kernel includes the macb/macb_pci driver and the relevant PCI-backed MACB device or driver path is available. The attacker then triggers driver removal, module unload, or an equivalent device unbind/removal sequence that causes macb_remove() to unregister clock structures. During platform_device_unregister(), runtime power-management callbacks may still execute and call macb_runtime_resume(), which attempts to prepare a clock object that has already been freed. This creates a kernel use-after-free condition. In straightforward cases the result is a kernel oops, panic, or service disruption; a more advanced attacker may try to shape heap state around the freed clock object to convert the stale pointer dereference into controlled kernel memory corruption and potential privilege escalation.

How to fix it

Upgrade to a vendor-supported Linux kernel that includes the upstream fix for the MACB PCI clock-handling use-after-free in the driver removal path. No exact fixed package versions were provided in the input, so use the relevant distribution kernel security advisory, stable kernel release notes, or vendor errata to identify the first patched kernel for each platform. If the MACB PCI driver is not required, mitigate by disabling or blacklisting macb_pci/macb, preventing the module from loading, or removing unused hardware exposure. Also restrict module load/unload and device unbind operations to trusted administrators, enable kernel lockdown where appropriate, and avoid unnecessary driver reload or hotplug workflows on affected systems until patched.

How to confirm the fix worked

Confirm remediation by verifying that the running kernel version matches a vendor build containing the MACB PCI clock lifetime fix, then reboot into that kernel if required. Check whether the affected modules are present with tools such as lsmod and modinfo, and confirm whether macb_pci or macb is loaded on systems where the driver is not expected. On non-production test systems with comparable hardware, validate that controlled driver unload/reload or device unbind/bind operations no longer produce KASAN, kernel oops, panic, or clk_prepare/macb_runtime_resume warnings. For mitigations, confirm module blacklisting or policy controls actually prevent the driver from loading and prevent untrusted users from invoking module-management or driver-unbind actions.

Typical attack path

1. Gain local access to an affected Linux system.
2. Confirm the vulnerable kernel includes the MACB Ethernet driver and PCI glue component, such as macb and macb_pci.
3. Trigger the vulnerable removal path through module unload, driver detach, PCI device unbind, or another local mechanism that invokes the MACB PCI driver removal logic.
4. Cause runtime power-management resume handling to run after clock structures have been unregistered and freed.
5. Exploit the resulting use-after-free to crash the kernel or attempt controlled kernel memory corruption for privilege escalation.

How to detect it

To assess possible prior exploitation or triggering, review kernel logs from journald, dmesg, syslog, crash dumps, pstore, and kdump/vmcore artifacts for use-after-free, KASAN, oops, panic, or call traces involving macb, macb_pci, clk_prepare, macb_runtime_resume, platform_device_unregister, or pci_device_remove. Review auditd or equivalent EDR telemetry for module-management activity, especially init_module, finit_module, delete_module, modprobe, rmmod, insmod, and writes to PCI driver bind/unbind sysfs paths near the time of crashes. Look for repeated unload/reload attempts of macb_pci, unexpected local users invoking module operations, privileged containers granted CAP_SYS_MODULE, or automation performing driver detach operations. Since no public exploit indicators or threat actors are known from the provided data, detection should focus on behavioral evidence of driver removal followed by kernel memory-safety errors or system crashes rather than fixed malware signatures.

• BUG: KASAN: use-after-free in clk_prepare
• clk_prepare+0x5a/0x60
• macb_runtime_resume
• macb_remove
• macb_probe
• macb_pci
• platform_device_unregister
• pci_device_remove
• __do_sys_delete_module
• delete_module
• rmmod macb_pci
• modprobe -r macb_pci
• rmmod macb
• modprobe -r macb
• /sys/bus/pci/drivers/macb_pci/unbind
• /sys/bus/pci/drivers/macb_pci/bind
• KASAN: use-after-free
• kernel BUG
• kernel panic
• Oops:

What your security team should do

• Inventory Linux systems for loaded or available macb and macb_pci kernel modules, prioritizing systems with matching hardware, virtualization test rigs, embedded platforms, or custom kernels.
• Patch affected systems with vendor-supported kernels containing the MACB PCI removal-path fix; prioritize hosts where local users, containers with elevated privileges, build systems, or device-management automation can influence kernel module or device removal.
• If the driver is unused, blacklist or disable macb_pci/macb and verify it is not loaded after reboot.
• Restrict CAP_SYS_MODULE, module unload, PCI driver unbind, and privileged container access; review sudo rules and automation that can run modprobe, rmmod, insmod, or write to sysfs driver bind/unbind files.
• Monitor kernel logs and audit logs for driver unloads, delete_module syscalls, device unbind activity, kernel oopses, KASAN reports, or crashes involving macb, macb_pci, clk_prepare, or macb_runtime_resume.
• Because EPSS is low, no exploit maturity is reported, and this is not in KEV, handle through normal kernel patch governance unless affected systems expose local multi-user or high-risk administrative surfaces.