CVE-2026-68135

What it actually does

This is a denial-of-service flaw in the Linux kernel hip04 Ethernet driver receive path. If build_skb() fails during hip04_rx_poll(), the driver can lose references to the current RX buffer and its DMA mapping while installing a replacement buffer, leaking memory and DMA resources. Repeated failures can progressively exhaust kernel/network resources, causing packet loss, interface instability, degraded networking, or system-wide resource pressure. The issue does not indicate code execution or privilege escalation by itself.

Why it matters to the business

Systems using the affected hip04 network driver may experience network degradation or outages if the receive path is stressed while memory allocation failures occur. For organizations running Linux on affected hardware, this can disrupt services that depend on network availability, increase operational incident load, and require emergency kernel maintenance. The CVE was published recently, is not currently listed in CISA KEV, and has no known public exploit maturity in the provided data, so urgency should be highest for exposed production systems using this driver rather than for all Linux systems universally.

How an attack unfolds

An attacker would need the vulnerable driver to be present and handling network traffic. The attacker sends or induces sufficient inbound traffic to exercise the hip04 receive path, ideally while the system is under memory pressure so build_skb() fails. In the vulnerable code path, the driver refills the RX slot incorrectly, overwriting references to the existing buffer and DMA mapping instead of preserving or freeing them. Repeating this condition leaks kernel-side receive buffers and DMA mappings until network or system resources are depleted. The practical outcome is denial of service through degraded receive processing, packet loss, interface malfunction, or broader kernel memory pressure. Exploitation is hardware- and configuration-dependent and is not expected to affect systems that do not use the hip04 Ethernet driver.

How to fix it

Apply a Linux kernel update that includes the upstream fix for the hip04 RX buffer leak. Because no exact fixed package versions were provided, use the fixed kernel version supplied by the relevant Linux distribution, appliance vendor, or hardware platform vendor once available. Prioritize systems where the hip04 Ethernet driver is compiled, loaded, and actively handling production traffic. If immediate patching is not possible, reduce exposure by moving critical workloads off affected hardware, limiting untrusted traffic to affected interfaces, rate-limiting inbound traffic where feasible, monitoring memory and RX error pressure, and rebooting only as a temporary recovery measure after resource exhaustion. Systems that do not include or use the hip04 driver are not expected to be exposed to this specific flaw.

How to confirm the fix worked

Confirm exposure by checking whether the running kernel includes the hip04 Ethernet driver and whether it is loaded or bound to an active network interface. Validate remediation by confirming the installed/running kernel package contains the vendor fix for this issue, then reboot into the fixed kernel if required. On source-based or custom kernels, confirm the hip04_rx_poll() error path preserves the current RX slot for NAPI retry when build_skb() fails and frees newly allocated RX fragments if dma_map_single() fails. Operationally validate by reviewing dmesg or journal logs after upgrade for absence of hip04-related RX allocation, DMA mapping, interface reset, or memory exhaustion symptoms under representative network load.

Typical attack path

1. Identify or assume a target Linux system using hardware supported by the hip04 Ethernet driver.
2. Generate sustained inbound network traffic toward the affected interface.
3. Increase the likelihood of allocation failure by timing traffic during resource pressure or by contributing to high memory/network load.
4. Trigger the vulnerable hip04_rx_poll() path where build_skb() fails.
5. Cause RX buffer and DMA mapping references to be overwritten and leaked during refill handling.
6. Repeat the condition until leaked resources cause packet loss, interface instability, or broader denial of service.

How to detect it

Historical exploitation is difficult to prove because the vulnerable path primarily causes resource leaks and denial-of-service symptoms rather than creating a distinctive file, process, or authentication artifact. Review kernel logs and system journals for hip04 driver messages, RX allocation failures, DMA mapping failures, memory exhaustion, NAPI stalls, interface resets, rapidly increasing RX drops, and network service disruption. Correlate these events with network telemetry showing sustained or unusual inbound traffic to affected interfaces. Useful log sources include dmesg, journald, /var/log/kern.log, /var/log/messages, network interface counters, performance telemetry for memory pressure, and packet-flow data. Because the known symptoms are generic, prioritize correlations where hip04-related kernel/resource errors occur shortly after high inbound traffic and improve after reboot or traffic reduction.

• hip04
• hip04_rx_poll
• build_skb
• build_skb() failed
• dma_map_single
• DMA mapping error
• DMA-API
• page allocation failure
• skb allocation failed
• out of memory
• Out of memory
• NAPI poll
• NETDEV WATCHDOG
• transmit queue timed out
• rx_dropped
• rx_errors
• /var/log/kern.log
• /var/log/messages

What your security team should do

• Inventory Linux systems and appliances using the hip04 Ethernet driver or affected HiSilicon/HIP04-class networking hardware.
• Prioritize patching for internet-facing, untrusted-network-facing, or high-throughput systems using this driver.
• Obtain fixed kernel packages from the operating system or device vendor and schedule reboots where required to activate the patched kernel.
• If patching is delayed, apply network rate limits, traffic filtering, or workload migration to reduce sustained untrusted inbound traffic to affected interfaces.
• Monitor kernel logs, memory pressure, RX drops, DMA mapping errors, and interface resets on potentially affected systems.
• Treat unexplained network degradation on affected hardware as potentially vulnerability-related, but recognize that available indicators are generic and may also reflect ordinary resource exhaustion or hardware faults.