CVE-2026-72380: xen/pvcalls: bound backend response req_id before indexing rsp[]
In the Linux kernel, the following vulnerability has been resolved:
xen/pvcalls: bound backend response reqid before indexing rsp[]
pvcallsfronteventhandler() takes reqid directly from the backend-supplied ring response and uses it to index the fixed-size bedata->rsp[] array for a memcpy() and a store, with no range check. A malicious or buggy backend can set reqid past PVCALLSNRRSPPERRING and drive an out-of-bounds write past the bedata allocation.
reqid was also declared int while the wire field rsp->reqid is u32, so a range check on the signed value alone is insufficient: a backend reqid of 0xffffffff becomes -1, passes a >= PVCALLSNRRSPPERRING test and indexes bedata->rsp[-1]. Declare reqid as u32 so a single bound covers both ends.
A backend that sends an out-of-range reqid has violated the wire protocol, so rather than silently dropping the response, log once and stop trusting the backend: set bedata->disabled. The event handler then ignores further responses, and the request paths that wait for a response return -EIO instead of blocking forever. This mirrors the fatal-error handling xen-netback uses (xenviffataltxerr()).
The pvcalls frontend currently trusts its backend, so this is not a classic-Xen security issue, but it matters for hardening PV frontends against malicious backends (confidential and disaggregated deployments).
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 6.1.191 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 6.6.160 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 6.12.114 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 6.18.57 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 7.1.5 - Upgrade
Upgrade
debian/linuxto a version that resolves this vulnerability.Fixed in 6.12.115-2 - Upgrade
Upgrade
debian/linuxto a version that resolves this vulnerability.Fixed in 7.1.5-1 - Upgrade
Upgrade
debian/linuxto a version that resolves this vulnerability.Fixed in 6.12.115-2Fixed in 7.2.12-1Fixed in 7.2.15-1 - Upgrade
Upgrade
ubuntu/linux-aws-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-1014.14~24.04.1 - Upgrade
Upgrade
ubuntu/linux-azure-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-1017.17~24.04.1 - Upgrade
Upgrade
ubuntu/linux-azure-fde-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-1016.16~24.04.1 - Upgrade
Upgrade
ubuntu/linux-gcp-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-1014.14~24.04.1 - Upgrade
Upgrade
ubuntu/linux-hwe-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-38.38~24.04.4 - Upgrade
Upgrade
ubuntu/linux-nvidia-tegrato a version that resolves this vulnerability.Fixed in 6.8.0-1035.38 - Upgrade
Upgrade
ubuntu/linux-oracle-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-1013.13~24.04.1 - Upgrade
Upgrade
ubuntu/linux-riscv-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-38.38.1~24.04.1 - Upgrade
Upgrade
ubuntu/linuxto a version that resolves this vulnerability.Fixed in 7.0.0-38.38 - Upgrade
Upgrade
ubuntu/linux-awsto a version that resolves this vulnerability.Fixed in 7.0.0-1014.14 - Upgrade
Upgrade
ubuntu/linux-azureto a version that resolves this vulnerability.Fixed in 7.0.0-1017.17 - Upgrade
Upgrade
ubuntu/linux-azure-fdeto a version that resolves this vulnerability.Fixed in 7.0.0-1016.16 - Upgrade
Upgrade
ubuntu/linux-gcpto a version that resolves this vulnerability.Fixed in 7.0.0-1014.14 - Upgrade
Upgrade
ubuntu/linux-gketo a version that resolves this vulnerability.Fixed in 7.0.0-1008.9 - Upgrade
Upgrade
ubuntu/linux-ibmto a version that resolves this vulnerability.Fixed in 7.0.0-1015.15 - Upgrade
Upgrade
ubuntu/linux-oem-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-1015.15 - Upgrade
Upgrade
ubuntu/linux-oracleto a version that resolves this vulnerability.Fixed in 7.0.0-1013.13 - Upgrade
Upgrade
ubuntu/linux-realtimeto a version that resolves this vulnerability.Fixed in 7.0.0-38.38.1 - Upgrade
Upgrade
ubuntu/linux-riscvto a version that resolves this vulnerability.Fixed in 7.0.0-38.38.1 - Configuration
Declare req_id as u32 so the range check covers the full wire-field range.
xen/pvcalls req_id declaration = u32 - Compensating control
In xen/pvcalls, validate the backend-supplied req_id against PVCALLS_NR_RSP_PER_RING before indexing bedata->rsp[], including rejecting values such as 0xffffffff that become negative when interpreted as signed.
- Compensating control
When an out-of-range req_id is received, log the protocol violation once, set bedata->disabled, ignore further responses, and make request paths waiting for a response return -EIO instead of blocking indefinitely.
Event History
Frequently Asked Questions
What is the severity of CVE-2026-72380?
CVE-2026-72380 has a risk score of 40, indicating a moderate severity vulnerability.
How do I fix CVE-2026-72380?
To fix CVE-2026-72380, update the affected Linux kernel to the latest patched version that resolves this vulnerability.
What systems are affected by CVE-2026-72380?
CVE-2026-72380 affects systems running vulnerable versions of the Linux kernel utilizing xen/pvcalls.
What types of attacks can exploit CVE-2026-72380?
Exploitation of CVE-2026-72380 could allow an attacker to gain unauthorized access or cause a denial of service through manipulation of backend response requests.
When was CVE-2026-72380 published?
CVE-2026-72380 was published on August 15, 2026.