CVE-2026-43445

What it actually does

This is a local availability flaw in the Linux kernel Intel e1000/e1000e Ethernet drivers. During transmit-buffer DMA mapping, if one mapping succeeds and a later mapping fails, the driver cleanup path unmaps one fewer DMA buffer than it should. Repeated failures can leak DMA mappings, eventually exhausting DMA/IOMMU resources or destabilizing the network device/driver. The practical impact is denial of service through degraded or failed networking and, depending on kernel configuration and system behavior under resource exhaustion, possible broader host instability. The vulnerability does not directly provide confidentiality or integrity impact and does not by itself grant code execution or privilege escalation.

Why it matters to the business

Systems using affected Linux kernels with e1000 or e1000e network drivers may experience network outages, degraded connectivity, or host instability if a local user or workload can repeatedly trigger the vulnerable transmit error path. This is most relevant for Linux servers, virtualized workloads, lab systems, appliances, or desktops using Intel e1000/e1000e-compatible NICs. The CVSS score indicates moderate severity with high availability impact, but current exploitation signals are low: EPSS is very low, no known CISA KEV listing is present, and no public exploit maturity is reported. Organizations should still remediate through normal kernel update cycles, prioritizing systems where untrusted local users, containers, or workloads can generate network traffic on affected hosts.

How an attack unfolds

An attacker first needs local execution capability, such as a shell account, compromised low-privileged process, or untrusted workload running on a system using an affected e1000/e1000e driver. The attacker then generates network transmit activity while attempting to create conditions that cause DMA mapping failures, such as memory pressure, IOMMU resource pressure, or other resource exhaustion scenarios. When the driver maps at least one transmit buffer successfully and a later mapping fails, the vulnerable cleanup path leaks one DMA mapping instead of unmapping all previously mapped buffers. By repeatedly exercising this error path, the attacker may consume DMA mapping resources and cause NIC transmit failures, kernel warnings, network hangs, or broader availability degradation. Exploitation is likely environment-dependent because the attacker must reliably trigger DMA mapping failures, which are not common during normal operation.

How to fix it

Apply a Linux kernel update from the operating system or appliance vendor that includes the e1000/e1000e DMA error cleanup fix for CVE-2026-43445. No exact fixed package versions were provided in the input, so use vendor advisories and distribution errata to identify the corrected kernel builds. After updating the kernel, reboot into the fixed kernel and verify that affected hosts are no longer running the vulnerable kernel image. Where immediate patching is not possible, reduce exposure by limiting local interactive access, restricting untrusted workloads on affected hosts, applying resource controls to containers and user processes, and monitoring for network-driver instability. If operationally feasible, avoid use of affected e1000/e1000e interfaces on high-risk multi-user systems until patched, or migrate workloads to systems using unaffected NIC drivers.

How to confirm the fix worked

Confirm exposure by checking whether the running kernel includes the vendor fix and whether active interfaces are bound to e1000 or e1000e. On Linux systems, validate the running kernel with commands such as `uname -r`, package-manager kernel inventory, and vendor advisory mappings. Check driver usage with `ethtool -i <interface>`, `readlink /sys/class/net/<interface>/device/driver`, or `lspci -k`. Confirm remediation by rebooting into the updated kernel and rechecking that the running kernel version matches a fixed vendor release. Review kernel logs after patching for absence of recurring DMA mapping failures, transmit queue timeouts, or e1000/e1000e hardware hang messages under normal traffic load.

Typical attack path

1. Gain local low-privileged execution on a Linux system using an affected e1000 or e1000e network driver.
2. Confirm the host is using the affected driver for an active network interface.
3. Generate sustained or crafted outbound network traffic to force transmit-buffer DMA mapping activity.
4. Induce or wait for DMA mapping failure conditions, commonly through memory or IOMMU resource pressure.
5. Repeatedly trigger the vulnerable TX cleanup path so one DMA mapping leaks per failed transmit-mapping sequence.
6. Cause resource exhaustion, network driver malfunction, transmit queue timeouts, or host/network denial of service.

How to detect it

Look for signs of prior exploitation or attempted triggering in host telemetry rather than network perimeter logs, because this is a local kernel-driver availability issue. Primary sources are kernel logs, systemd journal, `/var/log/kern.log`, `/var/log/messages`, `/var/log/syslog`, audit logs showing suspicious local workload activity, and monitoring data for NIC resets, transmit drops, IOMMU/DMA errors, or sudden network outages. Search for e1000/e1000e driver errors occurring alongside memory pressure, IOMMU faults, repeated outbound traffic generation, or process activity from low-privileged users. Indicators are circumstantial: DMA mapping failures and transmit hangs can occur for benign hardware or resource reasons, so correlate messages with repeated local traffic-generation processes, resource exhaustion, and recurring failures on affected kernels. There are no known public exploit-specific payload strings, command lines, files, registry keys, or network signatures for this issue based on the provided information.

• e1000e
• e1000
• DMA mapping failed
• dma_map_error
• NETDEV WATCHDOG
• transmit queue timed out
• Detected Hardware Unit Hang
• Tx Unit Hang
• Reset adapter unexpectedly
• DMA-API
• IOMMU
• DMAR

What your security team should do

• Inventory Linux systems using Intel e1000 or e1000e drivers, especially multi-user servers, virtualization hosts, appliances, and systems running untrusted local workloads.
• Prioritize kernel updates for affected systems where local users, containers, CI jobs, or third-party workloads can generate network traffic.
• Track vendor kernel advisories because fixed versions are distribution-specific and were not supplied in the input data.
• Reboot systems after patching and verify the running kernel, not only the installed package version.
• Monitor kernel logs for e1000/e1000e DMA mapping failures, transmit queue timeouts, and NIC reset/hang messages until remediation is complete.
• Restrict local access and enforce workload resource limits on systems that cannot be patched promptly.
• Because this is not currently listed in CISA KEV and has very low EPSS, handle as a normal-priority availability fix unless the affected system supports critical operations or untrusted local workloads.