Answer in brief
CVE-2026-72110 records a Unknown severity vulnerability in bpf,fork: wipe ->bpf_storage before bailouts that access it. 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.
A CVSS score is not reported in the current record. 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 | >=a10787e6d58c24b51e91c19c6d16c5da89fcaa4b <c3fd6f28c7ce1142a3b23dbb840eaa4777de1d74 || >=a10787e6d58c24b51e91c19c6d16c5da89fcaa4b <9cff220ddb65b022cc668bb652200742476e744c || >=a10787e6d58c24b51e91c19c6d16c5da89fcaa4b <c4f626ddf2350652ad2f79daf1f10847f3f6eabd || >=a10787e6d58c24b51e91c19c6d16c5da89fcaa4b <43f0005f81b8ce3be962d653cde8db9022f1e9b0 || >=a10787e6d58c24b51e91c19c6d16c5da89fcaa4b <9b51a6155d14389876916726430da30eabb1d4ed | c3fd6f28c7ce1142a3b23dbb840eaa4777de1d74, 9cff220ddb65b022cc668bb652200742476e744c, c4f626ddf2350652ad2f79daf1f10847f3f6eabd, 43f0005f81b8ce3be962d653cde8db9022f1e9b0, 9b51a6155d14389876916726430da30eabb1d4ed |
| Linux/Linuxgeneric | 5.13 | Not reported |
Published upstream
Aug 15, 2026
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Aug 15, 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,fork: wipe ->bpf_storage before bailouts that access it Currently, copy_process() can bail out to free_task() before p->bpf_storage has been initialized, with this call graph (shown here for the !CONFIG_MEMCG case): copy_process dup_task_struct arch_dup_task_struct [copies the entire task_struct, including ->bpf_storage member] [RLIMIT_NPROC check fails] delayed_free_task free_task bpf_task_storage_free rcu_dereference(task->bpf_storage) bpf_local_storage_destroy In this case, the nascent task's ->bpf_storage member that bpf_local_storage_destroy() operates on is a plain copy of the parent's ->bpf_storage pointer, not a real initialized pointer. This leads to badness (kernel hangs, UAF). This is reachable as long as the process calling fork() has been inserted into a task storage map.
Quoted source text, attributed separately from HOL analysis.
Answer in brief
CVE-2026-72110 records a Unknown severity vulnerability in bpf,fork: wipe ->bpf_storage before bailouts that access it. 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.
A CVSS score is not reported in the current record. 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 | >=a10787e6d58c24b51e91c19c6d16c5da89fcaa4b <c3fd6f28c7ce1142a3b23dbb840eaa4777de1d74 || >=a10787e6d58c24b51e91c19c6d16c5da89fcaa4b <9cff220ddb65b022cc668bb652200742476e744c || >=a10787e6d58c24b51e91c19c6d16c5da89fcaa4b <c4f626ddf2350652ad2f79daf1f10847f3f6eabd || >=a10787e6d58c24b51e91c19c6d16c5da89fcaa4b <43f0005f81b8ce3be962d653cde8db9022f1e9b0 || >=a10787e6d58c24b51e91c19c6d16c5da89fcaa4b <9b51a6155d14389876916726430da30eabb1d4ed | c3fd6f28c7ce1142a3b23dbb840eaa4777de1d74, 9cff220ddb65b022cc668bb652200742476e744c, c4f626ddf2350652ad2f79daf1f10847f3f6eabd, 43f0005f81b8ce3be962d653cde8db9022f1e9b0, 9b51a6155d14389876916726430da30eabb1d4ed |
| Linux/Linuxgeneric | 5.13 | Not reported |
Published upstream
Aug 15, 2026
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Aug 15, 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,fork: wipe ->bpf_storage before bailouts that access it Currently, copy_process() can bail out to free_task() before p->bpf_storage has been initialized, with this call graph (shown here for the !CONFIG_MEMCG case): copy_process dup_task_struct arch_dup_task_struct [copies the entire task_struct, including ->bpf_storage member] [RLIMIT_NPROC check fails] delayed_free_task free_task bpf_task_storage_free rcu_dereference(task->bpf_storage) bpf_local_storage_destroy In this case, the nascent task's ->bpf_storage member that bpf_local_storage_destroy() operates on is a plain copy of the parent's ->bpf_storage pointer, not a real initialized pointer. This leads to badness (kernel hangs, UAF). This is reachable as long as the process calling fork() has been inserted into a task storage map.
Quoted source text, attributed separately from HOL analysis.