Answer in brief
CVE-2026-72427 records a High severity (CVSS 7.8) vulnerability in bpf: Fix effective prog array index with BPF_F_PREORDER. The current sources do not mark it as known exploited. The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
Analysis pending evidence review
HOL Guard separates source facts from reviewed analysis. See the methodology.
CVSS is 7.8. The current sources do not mark it as known exploited. Treat this as a source-backed prioritization signal, not a statement about your environment.
Analysis status
Analysis pending evidence review
Factual feed record only; HOL analysis is not approved for indexing. Read the methodology.
The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
| Package | Affected range | Fixed version |
|---|---|---|
| Linux/Linuxgeneric | >=bc8023ef3b11410682e5d4990e05e5bc2d3e1c94 <525e408c27ae714e538b8c608c3a974df3ab6c92 || >=555c0b713ca83968d3c843cb15485b9ba3367b1b <41b4320b84fdafe1ab586b06453d30d50415db59 || >=4b82b181a26cff8bf7adc3a85a88d121d92edeaf <9697db03e010391c55ae75192cbdf30c5a72c114 || >=4b82b181a26cff8bf7adc3a85a88d121d92edeaf <b584f107ab90222bd825dcb4c5977326ff684109 || >=4b82b181a26cff8bf7adc3a85a88d121d92edeaf <f08aaee3152d0dfc578b3f2586932d82062701dd || 4707ad649cf662add3058bff47430817811b048d || >=6.6.93 <6.6.145 || >=6.12.31 <6.12.97 || >=6.14.9 <6.15 | 525e408c27ae714e538b8c608c3a974df3ab6c92, 41b4320b84fdafe1ab586b06453d30d50415db59, 9697db03e010391c55ae75192cbdf30c5a72c114, b584f107ab90222bd825dcb4c5977326ff684109, f08aaee3152d0dfc578b3f2586932d82062701dd, 6.6.145, 6.12.97, 6.15 |
| Linux/Linuxgeneric | 6.15 | Not reported |
Published upstream
Aug 15, 2026
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Aug 17, 2026
Evidence: source:cvelist:source_dates:source-dates:recordFirst seen by HOL
Aug 15, 2026
In the Linux kernel, the following vulnerability has been resolved: bpf: Fix effective prog array index with BPF_F_PREORDER replace_effective_prog() and purge_effective_progs() located the slot in the effective array by walking the program hlist and counting entries linearly. That count does not match the array layout: compute_effective_ progs() places BPF_F_PREORDER programs at the front (ancestor cgroup first, attach order within a cgroup) and the rest after them (descendant cgroup first). So when a preorder program is present, the linear hlist position no longer equals the program's index in the effective array. For replace_effective_prog() (bpf_link_update()) this overwrote the wrong slot, corrupting the effective order. For purge_effective_progs(), it could dummy out a slot belonging to a different program and leave the detached program in the array while bpf_prog_put() drops its reference, i.e. a use-after-free. Fix both by replaying compute_effective_progs()'s placement (including the per-cgroup preorder reversal) in a shared effective_prog_pos() helper. Identify the entry by its struct bpf_prog_list pointer rather than by (prog, link) value, so the lookup resolves to exactly the attachment the syscall selected even when the same bpf_prog is attached to several cgroups in the hierarchy.
Quoted source text, attributed separately from HOL analysis.