CVE-2026-74678 in Linux
Summary
by MITRE • 08/22/2026
In the Linux kernel, the following vulnerability has been resolved:
net: usb: ax88179_178a: fix skb leak in ax88179_tx_fixup()
When the interface has NETIF_F_SG enabled and skb_linearize() fails in ax88179_tx_fixup(), the function returns NULL without freeing the skb.
usbnet_start_xmit() treats a NULL return from tx_fixup() as a drop (info->flags does not set FLAG_MULTI_PACKET for this driver), jumping to the "drop" label where it does `if (skb) dev_kfree_skb_any(skb)`. Because tx_fixup() returned NULL, the local skb variable in usbnet_start_xmit() is NULL, so the original skb is never freed — a memory leak on every TX frame whose linearization fails (i.e. under memory pressure).
Free the skb before returning, matching the error handling already used for the pskb_expand_head() failure path in the same function.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 08/22/2026
The Linux kernel driver ax88179_178a manages USB-based Ethernet adapters and contains a critical resource management flaw within its transmission fixup routine. Specifically, the vulnerability resides in the ax88179_tx_fixup() function where an unhandled error condition leads to a memory leak. This issue manifests when the network interface has scatter-gather I/O capabilities enabled via NETIF_F_SG and the subsequent attempt to linearize the socket buffer fails due to insufficient kernel memory or other constraints. In such scenarios, the driver incorrectly returns NULL instead of properly cleaning up the allocated data structure, creating a persistent leak that degrades system stability over time under network load.
From a technical perspective, this flaw is classified as an improper resource cleanup mechanism, aligning with CWE-401 which describes missing release of memory after effective usage. The operational impact stems from how the upper-layer networking stack handles driver return codes. When ax88179_tx_fixup() returns NULL to indicate failure in linearizing the packet buffer, the calling function usbnet_start_xmit interprets this as a signal to drop the frame rather than transmit it. However, because the local variable holding the original socket buffer pointer is set to NULL by the failed fixup call, the subsequent error handling path that attempts to free the buffer via dev_kfree_skb_any() effectively operates on a null reference or skips execution entirely depending on implementation details, resulting in the original memory allocation never being released.
This vulnerability represents a classic resource exhaustion vector where repeated failures under high network throughput or low system memory conditions can gradually consume available kernel heap space. Over time, this unbounded growth of unreleased socket buffers contributes to increased latency, potential out-of-memory kills for critical processes, and eventual denial of service as the system becomes unable to allocate new resources for legitimate networking operations. The flaw is particularly insidious because it only triggers under specific conditions involving scatter-gather support and memory pressure, making it difficult to reproduce in standard testing environments without simulating constrained resource states.
Mitigation strategies primarily involve applying the upstream kernel patch that corrects this logic error by ensuring the socket buffer is freed before returning NULL from ax88179_tx_fixup(). This aligns with established best practices for driver development where all allocated resources must be released regardless of whether an operation succeeds or fails, except in cases where ownership has been explicitly transferred. Administrators should ensure their systems are updated to include this fix and monitor kernel logs for signs of memory pressure related to network subsystem allocations. From a defensive standpoint, implementing strict resource limits on socket buffer allocation can provide additional resilience against such leaks until the underlying code is patched.