Linux Kernel up to 7.1.4/7.2-rc1 xen/pvcalls class.c pvcalls_front_event_handler req_id out-of-bounds write

Summaryinfo

A vulnerability was found in Linux Kernel up to 7.1.4/7.2-rc1. It has been rated as very critical. This issue affects the function pvcalls_front_event_handler of the file class.c of the component xen/pvcalls. This manipulation of the argument req_id causes out-of-bounds write. This vulnerability is handled as CVE-2026-72380. The attack can be initiated remotely. There is not any exploit available.

Detailsinfo

A vulnerability classified as very critical was found in Linux Kernel up to 7.1.4/7.2-rc1. Affected by this vulnerability is the function pvcalls_front_event_handler of the file class.c of the component xen/pvcalls. The manipulation of the argument req_id with an unknown input leads to a out-of-bounds write vulnerability. The CWE definition for the vulnerability is CWE-787. The product writes data past the end, or before the beginning, of the intended buffer. As an impact it is known to affect confidentiality, integrity, and availability. The summary by CVE is:

In the Linux kernel, the following vulnerability has been resolved: xen/pvcalls: bound backend response req_id before indexing rsp[] pvcalls_front_event_handler() takes req_id 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 req_id past PVCALLS_NR_RSP_PER_RING and drive an out-of-bounds write past the bedata allocation. req_id was also declared int while the wire field rsp->req_id is u32, so a range check on the signed value alone is insufficient: a backend req_id of 0xffffffff becomes -1, passes a >= PVCALLS_NR_RSP_PER_RING test and indexes bedata->rsp[-1]. Declare req_id as u32 so a single bound covers both ends. A backend that sends an out-of-range req_id 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 (xenvif_fatal_tx_err()). 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).

It is possible to read the advisory at git.kernel.org. This vulnerability is known as CVE-2026-72380 since 08/09/2026. The exploitation appears to be easy. The attack can be launched remotely. The exploitation needs additional levels of successful authentication. Technical details of the vulnerability are known, but there is no available exploit. The pricing for an exploit might be around USD $5k-$25k at the moment (estimation calculated on 08/15/2026).

Upgrading to version 7.1.5 or 7.2-rc2 eliminates this vulnerability. Applying the patch d1297a9e2fd6ce08678b370d41bc980ca798f809/d33846c8dcc06b83b7acdeac1e8bfbb5c0c26cb2 is able to eliminate this problem.

Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.

Productinfo

Type

• Operating System

Vendor

• Linux

Name

• Kernel

Version

• 7.1.0
• 7.1.1
• 7.1.2
• 7.1.3
• 7.1.4
• 7.2-rc1

License

• open-source

Website

• Vendor: https://www.kernel.org/

CPE 2.3info

• 🔒
• 🔒
• 🔒

CPE 2.2info

• 🔒
• 🔒
• 🔒

CVSSv4info

CVSSv3info

CVSSv2info

Exploitinginfo

Threat Intelligenceinfo

Countermeasuresinfo

Timelineinfo

Sourcesinfo

Entryinfo

Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.

Discussion