GPU VulnDB

Database/Kernel, userspace & hypervisor

Xen netfront: backend-supplied short RX slot triggers BUG() in eth_type_trans or an over-read

UnscoredCVE-2026-98375Kernel, userspace & hypervisorcurated

Impact

xen-netfront pulls the first RX slot's length into the skb head before calling eth_type_trans(), and that length comes from the backend without being checked against ETH_HLEN. A backend that hands over a first slot shorter than an Ethernet header leaves the head shorter than skb->len and __skb_pull() hits a BUG(), panicking the guest; a whole packet shorter than ETH_HLEN makes eth_type_trans() read past the end of the data. This is XSA-522. For an operator running GPU workloads inside Xen guests, the result is a crashed VM - a guest-visible denial of service driven from outside the guest's control, and on a GPU VM a crash means re-attaching devices and losing the in-flight training or serving state.

Who can reach it

Requires a malicious or compromised network backend (driver domain / dom0 netback) facing the guest; it is not triggerable by an ordinary peer on the wire. The affected code is the paravirtual frontend, so only Xen guests using xen-netfront are exposed.

What to do

Update guest kernels to a stable release carrying the fix (commits linked in the record; see XSA-522 for the Xen advisory text) and reboot each affected guest. Hosts do not need patching for this one - the fix is in the frontend driver inside the VM. Where guest reboots are expensive, note that exploitation needs control of the backend, so the priority follows how much you trust the driver domain.

References

Related entries

All Kernel, userspace & hypervisor entries

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.