GPU VulnDB

Database/Kernel, userspace & hypervisor

Linux kernel xen/pvcalls: malicious backend req_id drives an out-of-bounds write in the PV frontend

CVSS 8.8CVE-2026-72380Kernel, userspace & hypervisorcurated

Impact

pvcalls_front_event_handler() took req_id straight from the backend-supplied ring response and used it to index a fixed-size rsp[] array for a memcpy() and a store with no range check, and declared it int while the wire field is u32 - so a backend req_id of 0xffffffff became -1 and indexed rsp[-1]. A backend that violates the wire protocol gets an out-of-bounds write past the bedata allocation inside the guest kernel. The upstream commit states plainly that the pvcalls frontend trusts its backend today, so this is not a classic Xen security boundary issue; it matters for confidential and disaggregated deployments where the backend is not part of the guest's trust base. The fix also marks the backend untrusted on protocol violation and fails waiting requests with -EIO instead of hanging.

Who can reach it

The Xen backend domain serving pvcalls to a guest, sending a response with an out-of-range req_id. No guest-side credentials involved; only relevant on guests that enable the pvcalls frontend, which most datacenter Xen guests do not.

What to do

Update guest kernels to a stable release with the bounded u32 req_id (three stable commits linked) and reboot the guests; it is a kernel change in the frontend driver. Guests not using pvcalls are unaffected, and a trusted backend removes the practical exposure. No vendor advisory with fixed version strings is in the record.

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.