Cloudanix VulnDB

CVE-2026-98375

None

CVSS

—

EPSS

0.2%

Published

Oct 9, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A flaw in how Linux handles certain network packets from a virtual machine host can let a malicious host crash the guest system or read a small amount of its memory.

Exploitation
Local Privilege
Attacker needs
High Privilege
Complexity
Moderate
Impact
Denial Of Service
Component
OS kernel
Class
Improper Input Validation
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

The xen/netfront driver fails to validate the length of the first RX slot against ETH_HLEN before calling eth_type_trans(), allowing skb data shorter than an Ethernet header. This triggers a BUG() in __skb_pull() when additional slots exist or an out-of-bounds read when the entire packet is undersized.

Why it matters to the business

A malicious or compromised Xen backend can crash the guest kernel or trigger memory-safety issues, causing denial of service for virtualized workloads and potential exposure of adjacent kernel memory in affected environments.

How an attack unfolds

An attacker controlling the Xen backend crafts an RX packet whose first slot is shorter than ETH_HLEN. The guest driver pulls insufficient data, eth_type_trans() either BUG()s or reads past the allocated buffer, resulting in a kernel panic or information leak.

How to fix it

Update to a Linux kernel containing the fix that enforces a minimum pull of ETH_HLEN and drops undersized packets. Apply the patch or newer stable kernel release that includes the change to xen/netfront receive handling.

How to confirm the fix worked

Confirm the kernel source contains the updated handle_incoming_queue() logic that checks pull length against ETH_HLEN and verifies the pull return value. Test with crafted short RX packets to ensure the guest no longer crashes or reads past the buffer.

Typical attack path

  1. Compromise or control the Xen backend for a target guest
  2. Send a network packet whose first RX slot is shorter than ETH_HLEN
  3. Trigger handle_incoming_queue() processing in the guest
  4. Cause eth_type_trans() to BUG() or perform an out-of-bounds read

How to detect it

Inspect kernel logs for xen_netfront or skb-related BUG() messages and oops traces referencing eth_type_trans or __skb_pull. Correlate with Xen backend packet lengths reported in dom0 logs or hypervisor traces.

What your security team should do

  • Prioritize kernel updates for all Xen guests within the next maintenance window given the 14-day public disclosure window
  • Monitor upstream Xen and distribution advisories for backported fixes
  • Consider network filtering at the hypervisor level to drop obviously malformed frames as a temporary layer

The record

In the Linux kernel, the following vulnerability has been resolved: xen/netfront: drop RX packets with a short Ethernet header handle_incoming_queue() pulls pull_to bytes into the head before calling eth_type_trans(). pull_to is the length of the first RX slot, capped at RX_COPY_THRESHOLD, and that length comes from the backend. Nothing checks it against ETH_HLEN. If the first slot is shorter than ETH_HLEN and more slots follow, the head ends up shorter than an Ethernet header while skb->len is longer, and eth_type_trans() BUG()s in __skb_pull(). If the whole packet is shorter than ETH_HLEN, eth_type_trans() reads the header past the end of the data instead. Pull at least ETH_HLEN, and drop the packet if that fails, which also drops packets too short to hold an Ethernet header. This also checks the return value of the pull, which was ignored.

Affected packages

Ecosystem Package Introduced Fixed