{ "schema_version": "1.6.1", "id": "RPI-CVE-2026-74371", "modified": "2026-10-09T11:39:44Z", "upstream": [ "CVE-2026-74371" ], "published": "2026-08-15T06:04:33Z", "summary": "bpf: fix BPF_PROG_QUERY OOB write and cgroup backward compat", "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 'query.revision' field unconditionally to\nuserspace. If userspace passes a smaller 'bpf_attr' structure (e.g. 40\nbytes, which was the layout before the addition of 'query.revision'),\nthe kernel performs an out-of-bounds write.\n\nFix this by propagating the user-provided attribute size 'uattr_size'\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 -> BPF_TCX_INGRESS/EGRESS\n- netkit_prog_query -> 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't 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.", "severity": [ { "type": "CVSS_V3", "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H" } ], "affected": [ { "package": { "ecosystem": "Raspberry Pi OS:13", "name": "linux" }, "versions": [ "1:6.18.29-1+rpt1", "1:6.18.33-1+rpt1", "1:6.18.34-1+rpt1", "1:6.18.39-1+rpt1" ], "ecosystem_specific": { "binaries": [ { "binary_name": "linux-image-6.18.29+rpt-rpi-2712", "binary_version": "1:6.18.29-1+rpt1" }, { "binary_name": "linux-image-6.18.29+rpt-rpi-v6", "binary_version": "1:6.18.29-1+rpt1" }, { "binary_name": "linux-image-6.18.29+rpt-rpi-v7", "binary_version": "1:6.18.29-1+rpt1" }, { "binary_name": "linux-image-6.18.29+rpt-rpi-v8", "binary_version": "1:6.18.29-1+rpt1" }, { "binary_name": "linux-image-6.18.29+rpt-rpi-v8-rt", "binary_version": "1:6.18.29-1+rpt1" }, { "binary_name": "linux-image-6.18.33+rpt-rpi-2712", "binary_version": "1:6.18.33-1+rpt1" }, { "binary_name": "linux-image-6.18.33+rpt-rpi-v6", "binary_version": "1:6.18.33-1+rpt1" }, { "binary_name": "linux-image-6.18.33+rpt-rpi-v7", "binary_version": "1:6.18.33-1+rpt1" }, { "binary_name": "linux-image-6.18.33+rpt-rpi-v8", "binary_version": "1:6.18.33-1+rpt1" }, { "binary_name": "linux-image-6.18.33+rpt-rpi-v8-rt", "binary_version": "1:6.18.33-1+rpt1" }, { "binary_name": "linux-image-6.18.34+rpt-rpi-2712", "binary_version": "1:6.18.34-1+rpt1" }, { "binary_name": "linux-image-6.18.34+rpt-rpi-v6", "binary_version": "1:6.18.34-1+rpt1" }, { "binary_name": "linux-image-6.18.34+rpt-rpi-v7", "binary_version": "1:6.18.34-1+rpt1" }, { "binary_name": "linux-image-6.18.34+rpt-rpi-v8", "binary_version": "1:6.18.34-1+rpt1" }, { "binary_name": "linux-image-6.18.34+rpt-rpi-v8-rt", "binary_version": "1:6.18.34-1+rpt1" }, { "binary_name": "linux-image-6.18.39+rpt-rpi-2712", "binary_version": "1:6.18.39-1+rpt1" }, { "binary_name": "linux-image-6.18.39+rpt-rpi-v6", "binary_version": "1:6.18.39-1+rpt1" }, { "binary_name": "linux-image-6.18.39+rpt-rpi-v7", "binary_version": "1:6.18.39-1+rpt1" }, { "binary_name": "linux-image-6.18.39+rpt-rpi-v8", "binary_version": "1:6.18.39-1+rpt1" }, { "binary_name": "linux-image-6.18.39+rpt-rpi-v8-rt", "binary_version": "1:6.18.39-1+rpt1" } ] }, "database_specific": { "per_version": { "1:6.18.29-1+rpt1": { "linux_commit": "66318c5b5cd8145a662303af12ed39ac07eb27cc", "upstream_version": "6.18.29", "assessment": "commit ancestry (strak rule)", "upstream_fixed": "6.18.40" }, "1:6.18.33-1+rpt1": { "linux_commit": "95b85bebbedcaedfa7ca79116ed38b7376fba412", "upstream_version": "6.18.33", "assessment": "commit ancestry (strak rule)", "upstream_fixed": "6.18.40" }, "1:6.18.34-1+rpt1": { "linux_commit": "c8c7494100e99ee05b11aaa4f0588a223a63d1af", "upstream_version": "6.18.34", "assessment": "commit ancestry (strak rule)", "upstream_fixed": "6.18.40" }, "1:6.18.39-1+rpt1": { "linux_commit": "60ea684a8ace97bb0db1a16e20753bdd6ab371ff", "upstream_version": "6.18.39", "assessment": "commit ancestry (strak rule)", "upstream_fixed": "6.18.40" } } } } ], "references": [ { "type": "ADVISORY", "url": "https://www.cve.org/CVERecord?id=CVE-2026-74371" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/b78eb6efbf052d44a3a14726aa7c7d5aa2e544d7" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/a7131340d0f95df9a541257dccab5d85e6bcdd2b" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/d3d630e8a7f3421bc2d204b87bdff35b4432a8e3" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/21c4b99b27f3f85b89256e81b3e997dec0a460d0" } ], "database_specific": { "source": "https://git.kernel.org/pub/scm/linux/security/vulns.git", "upstream_modified": "2026-09-14T12:06:03Z", "severity": { "source": "kernel CNA", "cvss_v3_score": 7.8, "cvss_v3_severity": "High", "scenario": "AV:L - The flaw is reached only through the bpf(2) syscall BPF_PROG_QUERY command on cgroup attach types via __sys_bpf()\u2192bpf_prog_query()\u2192cgroup_bpf_prog_query(); per kernel CNA guidance BPF/tc/netlink paths are Local, not Network.\nAC:L - The attacker fully controls the bpf_attr buffer, its declared size (e.g. 40 bytes pre-revision), placement in memory, cgroup2 target_fd, and attach_type; passing a short size reliably triggers the 8-byte revision copy_to_user at offset 56 with no race or external precondition.\nPR:L - bpf_prog_query() enforces bpf_net_capable(), requiring CAP_NET_ADMIN or CAP_SYS_ADMIN; both are delegable and obtainable inside an unprivileged user namespace (unshare -Urn) on typical distributions, so this is Low rather than init-namespace administrator.\nUI:N - Exploitation requires only the attacker's own bpf(BPF_PROG_QUERY) syscall (or an auto-invoked legacy-sized query after kernel upgrade); no separate victim mount, file open, or interactive action is needed.\nS:U - copy_to_user() writes past the caller-supplied userspace buffer boundary, corrupting adjacent mappings in the calling process; it does not corrupt kernel heap/slab memory or cross VM, IOMMU, or container-to-host security boundaries.\nC:H - The kernel performs an out-of-bounds 8-byte write past the declared bpf_attr size; per CNA guidance any such memory corruption can be leveraged for information disclosure via adjacent userspace secrets, not merely a bounded metadata leak.\nI:H - The unconditional copy_to_user of query.revision at offset 56 when size is below offsetofend(revision) is an out-of-bounds write of up to 8 bytes (revision value partly influenced by prior cgroup BPF attach/detach), enabling userspace heap/stack corruption and potential code execution.\nA:H - The OOB write can crash or hang privileged BPF/cgroup management daemons (containerd, Cilium, kubelet) still issuing legacy-sized BPF_PROG_QUERY after a 6.17+ upgrade, and malicious CAP_NET_ADMIN callers can repeatedly corrupt adjacent mappings to induce process termination." } } }