Cloudanix VulnDB

CVE-2026-99057

None

CVSS

—

EPSS

0.2%

Published

Oct 23, 2026

CISA due date

—

Cloudanix analysis

Next patch cycle SSVC: Track

A bug in Linux virtual machine networking code can slowly leak memory when talking to certain virtual network backends, eventually causing slowdowns or crashes if left unpatched.

Exploitation
Remote Authenticated
Attacker needs
High Privilege
Complexity
Low
Impact
Denial Of Service
Component
OS kernel
Class
Memory Corruption
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

Memory leak of skb structures and attached page fragments in the xen/netfront driver when xennet_fill_frags() encounters an oversized response chain that exceeds skb frags capacity, bypassing the normal error-path free logic.

Why it matters to the business

Gradual exhaustion of kernel memory in Xen guest networking stacks when communicating with a malicious or compromised backend, potentially leading to performance degradation or denial of service after sustained operation.

How an attack unfolds

An attacker controlling the Xen backend sends network response chains with more slots than the guest skb can accommodate; xennet_fill_frags() fails and the error path in xennet_poll() frees only the tmpq remainder while the partially filled skb is lost, repeating the process to accumulate leaks.

How to fix it

Apply the upstream kernel fix that restores the skb to tmpq before the error path in xennet_poll(), or upgrade to a Linux kernel release containing the resolution for this netfront leak.

How to confirm the fix worked

Inspect xen/netfront.c for the presence of the skb restoration step before the errq handling block; verify kernel version or changelog entry matches the published fix; monitor for absence of repeated xennet error paths under synthetic oversized-chain tests.

Typical attack path

  1. Establish Xen para-virtualized network connection with netfront driver
  2. Backend transmits oversized response descriptor chains exceeding skb frags limit
  3. xennet_fill_frags() returns error and control jumps to error path without restoring skb to tmpq
  4. Leaked skb and pages accumulate in guest kernel memory
  5. Repeated chains cause progressive memory exhaustion

How to detect it

Review kernel logs for xennet_poll error paths combined with rising slab or page allocation metrics; correlate with Xen backend activity logs showing unusually long response chains.

What your security team should do

  • Prioritize kernel upgrade for all Xen guests using netfront networking within the next maintenance window
  • Monitor memory usage trends on affected guests for unexplained growth
  • Review Xen backend configurations to ensure only trusted dom0 instances are used

The record

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.

Affected packages

Ecosystem Package Introduced Fixed