Answer in brief
CVE-2026-72431 records a Unknown severity vulnerability in alloc_tag: fix use-after-free in /proc/allocinfo after module unload. 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 | >=9f44df50fee4d2f6cb374177244ccfa9f0a5cc95 <37e3e8a2c3bfdd503209f043f8bbfbdcf5a1d92f || >=9f44df50fee4d2f6cb374177244ccfa9f0a5cc95 <008ceffd44040f809aead6d7bef7cb1210c4149a || >=9f44df50fee4d2f6cb374177244ccfa9f0a5cc95 <2956268efc457cb05d29c1bf94de1e8e684d7bbc | 37e3e8a2c3bfdd503209f043f8bbfbdcf5a1d92f, 008ceffd44040f809aead6d7bef7cb1210c4149a, 2956268efc457cb05d29c1bf94de1e8e684d7bbc |
| Linux/Linuxgeneric | 6.17 | 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: alloc_tag: fix use-after-free in /proc/allocinfo after module unload allocinfo_start() only reinitializes the codetag iterator at position 0. For subsequent reads (position > 0), it reuses cached iterator state from the previous batch. allocinfo_stop() drops mod_lock between read batches, which allows module unload to complete and free the module memory that the cached iterator still references: CPU0 (read) CPU1 (rmmod) ---- ---- allocinfo_start(pos=0) down_read(mod_lock) allocinfo_show() ... allocinfo_stop() up_read(mod_lock) codetag_unload_module() kfree(cmod) release_module_tags() ... free_mod_mem() allocinfo_start(pos=N) down_read(mod_lock) // reuses cached iter, skips re-init allocinfo_show() ct->filename <-- UAF After free_mod_mem() frees the module's .rodata, allocinfo_show() dereferences ct->filename, ct->function which point there. Save the iterator state in allocinfo_next() and resume from it in allocinfo_start() with codetag_next_ct(), which detects module removal via idr_find() returning NULL and skips to the next module.
Quoted source text, attributed separately from HOL analysis.
Answer in brief
CVE-2026-72431 records a Unknown severity vulnerability in alloc_tag: fix use-after-free in /proc/allocinfo after module unload. 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 | >=9f44df50fee4d2f6cb374177244ccfa9f0a5cc95 <37e3e8a2c3bfdd503209f043f8bbfbdcf5a1d92f || >=9f44df50fee4d2f6cb374177244ccfa9f0a5cc95 <008ceffd44040f809aead6d7bef7cb1210c4149a || >=9f44df50fee4d2f6cb374177244ccfa9f0a5cc95 <2956268efc457cb05d29c1bf94de1e8e684d7bbc | 37e3e8a2c3bfdd503209f043f8bbfbdcf5a1d92f, 008ceffd44040f809aead6d7bef7cb1210c4149a, 2956268efc457cb05d29c1bf94de1e8e684d7bbc |
| Linux/Linuxgeneric | 6.17 | 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: alloc_tag: fix use-after-free in /proc/allocinfo after module unload allocinfo_start() only reinitializes the codetag iterator at position 0. For subsequent reads (position > 0), it reuses cached iterator state from the previous batch. allocinfo_stop() drops mod_lock between read batches, which allows module unload to complete and free the module memory that the cached iterator still references: CPU0 (read) CPU1 (rmmod) ---- ---- allocinfo_start(pos=0) down_read(mod_lock) allocinfo_show() ... allocinfo_stop() up_read(mod_lock) codetag_unload_module() kfree(cmod) release_module_tags() ... free_mod_mem() allocinfo_start(pos=N) down_read(mod_lock) // reuses cached iter, skips re-init allocinfo_show() ct->filename <-- UAF After free_mod_mem() frees the module's .rodata, allocinfo_show() dereferences ct->filename, ct->function which point there. Save the iterator state in allocinfo_next() and resume from it in allocinfo_start() with codetag_next_ct(), which detects module removal via idr_find() returning NULL and skips to the next module.
Quoted source text, attributed separately from HOL analysis.