CVE-2026-99057 in Linux
Summary
by MITRE • 10/23/2026
In the Linux kernel, the following vulnerability has been resolved:
xen/netfront: don't leak the skb when xennet_fill_frags() fails
When a response chain has more slots than fit in the skb's frags, xennet_fill_frags() returns an error and xennet_poll() jumps to its error path. That path moves what's left on tmpq to errq to be freed, but the skb being filled was already dequeued from tmpq, so it's never freed. Each chain that overflows leaks the skb and the pages attached to it as frags, and the backend decides how many slots it sends.
Put the skb back on tmpq before taking the error path, like the xennet_set_skb_gso() failure just above it does.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 10/23/2026
The Linux kernel vulnerability identified in the Xen network frontend driver involves a resource leak within the packet processing logic of the xennet_fill_frags function. This issue arises during the handling of response chains from the virtualized backend, where the number of slots provided exceeds the capacity of the socket buffer's fragment array. When this overflow condition occurs, the fill operation fails and returns an error code. The subsequent control flow in the polling routine attempts to clean up by moving remaining items on a temporary queue to an error queue for eventual freeing. However, because the specific socket buffer being processed had already been dequeued from that temporary queue prior to the failure check, it is not included in the cleanup operation and consequently remains unfreed in memory.
This technical flaw results in a progressive memory leak affecting both the kernel's socket buffer structures and the underlying page frames attached as fragments. Since the backend controls the number of slots sent per response chain, an attacker or misbehaving virtual machine could potentially trigger this condition repeatedly by sending large packets with excessive slot counts. Over time, these unreleased resources consume available kernel memory, leading to increased pressure on system resources. In severe cases, continuous exploitation can degrade network performance due to resource exhaustion or even cause a denial of service if the kernel runs out of allocatable memory for new network operations.
From a classification perspective, this vulnerability aligns with CWE-401, which describes a missing release of memory after effective usage, and specifically relates to improper cleanup procedures in error handling paths. In terms of attack vectors, while primarily impacting availability through resource exhaustion rather than direct code execution or privilege escalation, it falls under the broader category of Denial of Service attacks within the MITRE ATT&CK framework. The root cause is a logic error where state management fails to account for objects that have been removed from tracking structures before an exception occurs.
To mitigate this vulnerability, the fix involves modifying the control flow in xennet_poll to ensure that any socket buffer currently being processed is returned to the temporary queue if the fill operation fails. This ensures that the subsequent error handling path correctly identifies and frees all relevant resources associated with the failed packet processing cycle. System administrators should apply kernel updates provided by their distribution vendors as soon as they become available, ensuring that the patched version of the Xen network frontend driver is active on affected virtual machines to prevent further memory leaks and maintain system stability under high-load or adversarial conditions.