CVE-2026-43283

What it actually does

This is a Linux kernel memory-corruption flaw in the ec_bhf Ethernet driver error path. The driver passes an allocation length field to dma_free_coherent() where a DMA handle is expected, causing the kernel to unmap or free the wrong DMA address when receive-buffer setup fails. If an attacker can cause or reach that error path on a system using the affected driver, the result can be kernel memory corruption, DMA mapping corruption, kernel crash, or potentially local privilege escalation with kernel-level code execution. The CVSS vector indicates local access, low attack complexity, low privileges required, no user interaction, and high confidentiality, integrity, and availability impact.

Why it matters to the business

Successful exploitation could allow a local user or compromised low-privilege process to crash an affected Linux host or potentially gain full control of the operating system. The practical risk is highest on systems that load or use the ec_bhf Ethernet driver, particularly industrial, embedded, or specialized Linux deployments using the relevant hardware. This issue is not currently listed in CISA KEV, is not known to be used in ransomware campaigns, has low EPSS, and has no public exploit maturity reported, so it should be prioritized as a kernel hardening and exposure-reduction issue rather than an active mass-exploitation emergency.

How an attack unfolds

An attacker first needs local code execution with low privileges on a Linux system that includes the vulnerable kernel code and where the ec_bhf Ethernet driver can be loaded, initialized, or exercised. The attacker then attempts to trigger the driver's receive-buffer allocation or initialization failure path, for example by repeatedly manipulating device initialization conditions, driver load/unload behavior, resource pressure, or other local conditions that force the error path. When the driver unwinds the failed allocation, it calls dma_free_coherent() with the wrong value as the DMA handle. That can corrupt DMA bookkeeping or unmap an unintended address. Depending on kernel configuration, hardware state, allocator layout, and timing, exploitation may result in a kernel warning, panic, denial of service, or a controlled memory-corruption primitive that could be chained into privilege escalation.

How to fix it

Upgrade the Linux kernel to a vendor or distribution release that includes the upstream ec_bhf fix changing the dma_free_coherent() argument from the receive-buffer allocation length to the correct DMA handle. Because no exact fixed package versions were provided, use the latest stable kernel from the relevant Linux distribution or hardware vendor and verify that the patch for the ec_bhf DMA-free fix is included. Where immediate patching is not possible, mitigate by disabling or blacklisting the ec_bhf driver if the hardware is not required, preventing unprivileged users from loading kernel modules, restricting local shell access, reducing unnecessary user accounts, and applying standard kernel hardening controls such as module signing, lockdown mode, and least-privilege access controls.

How to confirm the fix worked

Confirm remediation by verifying the running kernel version is at or above the vendor release containing the ec_bhf DMA-handle fix, and by checking vendor changelogs or source packages for the corrected dma_free_coherent() call using priv->rx_buf.alloc_phys. Validate exposure by checking whether the ec_bhf module exists or is loaded with commands such as lsmod, modinfo ec_bhf, and inspection of /lib/modules/$(uname -r)/. If the driver is not present, not loadable, or the system does not use the relevant hardware, exposure is materially reduced. After patching or mitigation, reboot into the fixed kernel and confirm the old vulnerable kernel is not still the active boot target.

Typical attack path

1. Obtain low-privileged local execution on a Linux system.
2. Confirm the affected kernel includes the ec_bhf Ethernet driver and that the driver is loaded or loadable.
3. Cause the ec_bhf driver initialization or receive-buffer allocation path to fail under attacker-influenced conditions.
4. Trigger the erroneous dma_free_coherent() call using the allocation length value instead of the DMA handle.
5. Leverage the resulting DMA mapping or kernel memory corruption to crash the host or attempt privilege escalation.
6. Cover tracks by removing local exploit artifacts and relying on the fact that symptoms may appear as kernel or driver instability.

How to detect it

Review kernel logs, system journal entries, crash dumps, and EDR telemetry for signs that the ec_bhf driver was loaded and then encountered DMA, allocation, or cleanup failures. Useful sources include journalctl -k, /var/log/kern.log, /var/log/messages, /var/log/syslog, dmesg output, kdump/vmcore artifacts, audit logs for module loading, and process telemetry showing repeated modprobe, insmod, rmmod, or stress/resource-exhaustion commands near the time of a kernel warning or crash. Look for DMA-API warnings, kernel oops or panic messages, call traces referencing ec_bhf, dma_free_coherent, or receive-buffer cleanup, and repeated local user activity preceding host instability. Because no public exploit indicators are known, detection should focus on behavioral signs of local kernel exploitation attempts rather than fixed network indicators.

• ec_bhf
• modprobe ec_bhf
• insmod ec_bhf
• rmmod ec_bhf
• dma_free_coherent
• DMA-API
• DMA-API: debugging check
• kernel BUG
• kernel panic
• Oops:
• Call Trace:
• ec_bhf_rx
• ec_bhf_probe
• ec_bhf_remove
• priv->rx_buf.alloc_len
• priv->rx_buf.alloc_phys

What your security team should do

• Inventory Linux systems for affected kernels and for presence or use of the ec_bhf Ethernet driver.
• Prioritize patching systems where ec_bhf is loaded, relevant hardware is present, or local multi-user access is allowed.
• Deploy vendor-fixed kernel updates and reboot systems to ensure the fixed kernel is active.
• If the driver is unnecessary, blacklist or remove ec_bhf and enforce controls that prevent unprivileged module loading.
• Monitor kernel logs for DMA-API errors, ec_bhf driver failures, kernel oops events, panics, or repeated driver load/unload activity.
• Treat suspicious local exploitation attempts as potential privilege-escalation activity and review user command history, process execution telemetry, and authentication logs around kernel fault times.
• Because exploitation is not currently known in the wild and EPSS is low, manage this through normal high-severity kernel patch SLAs, accelerating for exposed industrial or embedded Linux systems.