CVE-2026-68135: HiSilicon P04 Ethernet Leak Fixed

The National Vulnerability Database added the record on August 10, 2026, using kernel.org’s description and stable-kernel fix references. The affected code is in

, specifically the receive-side NAPI polling routine,

. The Linux Kernel Driver Database separately identifies the driver as

, a configurable driver intended for the internal Ethernet controller in HiSilicon P04 SoCs.

The operational impact is a gradual leak of receive-buffer memory and DMA mappings after an allocation-related failure. It is a reliability and resource-accounting defect in a hardware-specific network driver, not a demonstrated remote-code-execution or local-privilege-escalation issue. NVD has not assigned CVSS v2, v3, or v4 metrics, nor has it assigned a CWE category, as of August 11.

The failed recovery path lost ownership of the RX buffer​

The relevant driver keeps a ring of receive-buffer slots. When a packet arrives,

calls

to wrap the current raw receive buffer in Linux’s

packet structure. If that succeeds, the driver unmaps the DMA address, processes or drops the packet as appropriate, allocates a replacement fragment, maps it for DMA, and installs that replacement in the ring.

The older failure path handled

returning

by jumping directly to the common refill code. That was the wrong point to resume. The current buffer was still owned by the driver and still had an active DMA mapping, but the refill code allocated a new buffer and overwrote the ring slot’s pointers with it.

The original buffer and its mapping then had no remaining reference the driver could later clean up. Under repeated failures, the affected system could consume memory and DMA mapping resources until networking became unstable or the machine encountered broader memory pressure.

The flaw has a second, smaller leak in the same replacement path. If the driver successfully allocates a new receive fragment but

fails, the fragment must be freed; the vulnerable path abandoned it instead.

This is why the CVE description calls out two resources rather than merely “a memory leak.” The first error path loses both an RX fragment and an existing DMA mapping. The second loses a newly allocated fragment when mapping it fails.

The fix retries instead of replacing the live slot​

The upstream repair changes the logic at the point where

fails. Rather than entering the refill sequence, the driver preserves the current RX-ring slot and returns its full NAPI processing budget. That tells the networking subsystem that the poll cycle has not completed its available work and allows the same receive buffer to be retried later.

It is a deliberately conservative recovery model: do not discard or replace a buffer until ownership has been transferred successfully. The replacement-buffer path remains reserved for packets whose old buffer was actually consumed, while an allocation failure leaves the existing DMA-backed buffer in place.

The patch also releases a just-allocated fragment when

returns an error. That closes the second leak and makes both failure paths match the driver’s normal ownership rules.

Kernel developers describe the issue as found by an in-house static-analysis tool. That detail matters: the public record identifies a reachable cleanup error, but it does not document a field crash, a proof of exploitation, a required packet sequence, or an affected product deployment. The evidence currently supports treating CVE-2026-68135 as a defect worth patching on exposed hardware, not as a reason to assume compromise.

A 2016 error-handling change is the affected baseline​

NVD’s affected-version data names Git commit

as the start of the vulnerable range and lists Linux kernel 4.5 onward as affected until the relevant stable fixes. That lower bound is more informative than the broad version number: a Linux Wireless pull request archive identifies that January 13, 2016 commit as

.

In other words, the CVE appears to stem from an earlier attempt to deal with

failure. That prior work made the failure path explicit, but routed it through the receive-ring refill logic before releasing — or preserving — the resources already attached to the slot. The new fix corrects the ownership mistake.

There is a potential source of confusion here. The Linux Kernel Driver Database shows that

existed as a driver option as early as Linux 4.0, while NVD marks the vulnerable code path as beginning at Linux 4.5. Those statements do not conflict: the driver itself predates the particular error-handling change that NVD identifies as the vulnerable baseline.

For administrators, the version range alone is therefore insufficient. A kernel can contain the HiSilicon P04 driver and still be irrelevant if it was built without

, is not running on compatible hardware, or is from before the affected code entered the tree.

Stable fixes are already identified​

NVD’s record names corrected upstream stable releases for the maintained lines:

The CVE record also references five stable commits, one for each maintained branch receiving the correction. Distribution maintainers may ship the patch under a vendor kernel version that does not visibly match those upstream numbers, so the decisive evidence on enterprise systems is the distribution’s kernel changelog or security advisory rather than

alone.

No distribution-specific advisories, package names, severity ratings, or backport status are included in the NVD entry. That omission is material for fleet operators: the CVE is published, upstream fixes are available, but the record does not tell administrators whether a given Red Hat, SUSE, Ubuntu, Debian, Oracle, appliance, or embedded-vendor kernel has incorporated them.

How to determine whether a system is exposed​

The driver is specifically gated by the kernel configuration symbol

. Linux’s own Kconfig help says it is for systems with a HiSilicon P04 SoC that use the internal Ethernet controller; the driver is built as

. Current kernel configuration also places it under ARM, ARM64, or compile-test builds, reinforcing that this is not an x86 PC Ethernet-driver issue.

Administrators maintaining ARM appliances, older networking equipment, or custom embedded Linux images should check the running kernel configuration first:

A value of

means the driver is built into the kernel. A value of

means it is available as a module, in which case

can determine whether it is loaded. If the option is absent or explicitly unset, this CVE’s affected code is not present in that kernel build.

A loaded module alone is still not the entire exposure test. The driver binds to Device Tree hardware identified as

; a generic ARM board with the module available but no matching P04 Ethernet controller cannot exercise this receive path. Conversely, a custom appliance image may build the driver in and hide that fact behind a vendor-specific kernel package, making configuration inspection more useful than relying on a hardware inventory label.

Windows administrators can close this ticket unless they also administer a separate Linux-based ARM appliance or embedded workload. Updating Windows, Windows Server, Hyper-V, or WSL for CVE-2026-68135 would not repair the vulnerable driver because none uses the HiSilicon P04 internal Ethernet controller as its host networking device.

Patch the relevant appliance kernel, not every Linux machine​

For systems that do use the P04 Ethernet controller, the right action is straightforward: move to a vendor kernel containing the upstream fix, or backport the narrow

change if the platform is maintained on a pinned kernel. The patch corrects cleanup under exceptional allocation and DMA-mapping failures; it should be treated as normal kernel maintenance for a device that must remain available under memory pressure or hardware-mapping faults.

For everyone else, the important conclusion is equally straightforward: this is a hardware- and configuration-specific Linux driver CVE, not a cross-platform networking emergency. The stable fixes are already known, but the remaining work is for embedded and appliance vendors to state clearly which shipped kernel packages include them.