GHSA-WG9F-H9HG-J36P
Vulnerability from github – Published: 2026-08-15 06:32 – Updated: 2026-08-17 06:33In the Linux kernel, the following vulnerability has been resolved:
bpf: fix BPF_PROG_QUERY OOB write and cgroup backward compat
BPF_PROG_QUERY writes back the 'query.revision' field unconditionally to userspace. If userspace passes a smaller 'bpf_attr' structure (e.g. 40 bytes, which was the layout before the addition of 'query.revision'), the kernel performs an out-of-bounds write.
Fix this by propagating the user-provided attribute size 'uattr_size' down to the cgroup query handlers, and conditionally skipping writing the revision field to userspace when the provided buffer size is insufficient.
query.revision in bpf_mprog_query is structurally identical to the cgroup case: a late tail field, written unconditionally.
But the backward-compat hazard is not the same.
The min-historical-size test is per command, and bpf_mprog_query only serves attach types that were born with revision in the struct:
- tcx_prog_query -> BPF_TCX_INGRESS/EGRESS
- netkit_prog_query -> BPF_NETKIT_PRIMARY/PEER
tcx, netkit, the revision field, and bpf_mprog_query itself all landed in the same v6.6 merge window (053c8e1f235d added the mprog query API + revision; tcx in e420bed02507, netkit in 35dfaad7188c). There has never been a tcx/netkit BPF_PROG_QUERY userspace that doesn't know about revision. So for these commands the minimum legitimate struct already covers offset 56-64 — no old binary can be broken here.
Contrast with cgroup: BPF_PROG_QUERY on cgroup attach types shipped in 2017; revision write-back was bolted on years later (120933984460). That path has a real population of pre-revision callers.
{
"affected": [],
"aliases": [
"CVE-2026-74371"
],
"database_specific": {
"cwe_ids": [],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-08-15T06:22:38Z",
"severity": "HIGH"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nbpf: fix BPF_PROG_QUERY OOB write and cgroup backward compat\n\nBPF_PROG_QUERY writes back the \u0027query.revision\u0027 field unconditionally to\nuserspace. If userspace passes a smaller \u0027bpf_attr\u0027 structure (e.g. 40\nbytes, which was the layout before the addition of \u0027query.revision\u0027),\nthe kernel performs an out-of-bounds write.\n\nFix this by propagating the user-provided attribute size \u0027uattr_size\u0027\ndown to the cgroup query handlers, and conditionally skipping writing\nthe revision field to userspace when the provided buffer size is\ninsufficient.\n\nquery.revision in bpf_mprog_query is structurally identical to the\ncgroup case: a late tail field, written unconditionally.\n\nBut the backward-compat hazard is not the same.\n\nThe min-historical-size test is per command, and bpf_mprog_query only\nserves attach types that were born with revision in the struct:\n\n- tcx_prog_query -\u003e BPF_TCX_INGRESS/EGRESS\n- netkit_prog_query -\u003e BPF_NETKIT_PRIMARY/PEER\n\ntcx, netkit, the revision field, and bpf_mprog_query itself all landed in\nthe same v6.6 merge window (053c8e1f235d added the mprog query API +\nrevision; tcx in e420bed02507, netkit in 35dfaad7188c). There has never\nbeen a tcx/netkit BPF_PROG_QUERY userspace that doesn\u0027t know about\nrevision. So for these commands the minimum legitimate struct already\ncovers offset 56-64 \u2014 no old binary can be broken here.\n\nContrast with cgroup: BPF_PROG_QUERY on cgroup attach types shipped in\n2017; revision write-back was bolted on years later (120933984460). That\npath has a real population of pre-revision callers.",
"id": "GHSA-wg9f-h9hg-j36p",
"modified": "2026-08-17T06:33:41Z",
"published": "2026-08-15T06:32:31Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-74371"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/21c4b99b27f3f85b89256e81b3e997dec0a460d0"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a7131340d0f95df9a541257dccab5d85e6bcdd2b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d3d630e8a7f3421bc2d204b87bdff35b4432a8e3"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.