Answer in brief
CVE-2026-98832 records a Unknown severity vulnerability in blk-cgroup: save IRQ state in blkg_tryget_closest(). 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 | >=9327a865e395a53f67dffac4710beb1d4730495e <9fcf4317384ce6758c3127a6e8914c54cbb9c8cc || >=9327a865e395a53f67dffac4710beb1d4730495e <327c428ba79b13e4cc5253333a9d5c0aa5579bdf | 9fcf4317384ce6758c3127a6e8914c54cbb9c8cc, 327c428ba79b13e4cc5253333a9d5c0aa5579bdf |
| Linux/Linuxgeneric | 7.2 | Not reported |
Published upstream
Oct 18, 2026
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Oct 18, 2026
Evidence: source:cvelist:source_dates:source-dates:recordFirst seen by HOL
Oct 18, 2026
In the Linux kernel, the following vulnerability has been resolved: blk-cgroup: save IRQ state in blkg_tryget_closest() bio_set_dev() associates the bio with a blkg through bio_associate_blkg(). If the blkg lookup misses, blkg_tryget_closest() takes q->queue_lock with spin_lock_irq() and releases it with spin_unlock_irq(), which unconditionally enables local interrupts. Callers may call bio_set_dev() with interrupts already disabled, e.g. dm-thin's pool_map() does so while holding pool->lock taken with spin_lock_irq(). The nested spin_unlock_irq() then enables interrupts while pool->lock is still held, so an I/O completion softirq can run on the same CPU, re-acquire pool->lock (thin_endio(), or overwrite_endio() -> complete_mapping_preparation()) and deadlock. lockdep reports this as inconsistent SOFTIRQ-ON-W to IN-SOFTIRQ-W usage. Commit 3a762de55b4e ("block: save irq state in blkg_lookup_create()") fixed the same problem while the lock lived in blkg_lookup_create(), but commit 9327a865e395 ("blk-cgroup: don't nest queue_lock under rcu in blkg_lookup_create()") moved the locking into blkg_tryget_closest() and reverted it to spin_lock_irq(). Save and restore the caller's IRQ state instead.
Quoted source text, attributed separately from HOL analysis.