Answer in brief
CVE-2026-80808 records a Unknown severity vulnerability in ext4: stop retrying saturated xattr cache entries. 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 | >=1a56cd972ce121b6cf2517a47a578782bbd2ec95 <119a2f053242ed75bdd2ebc95baf3ae7db6ccacf || >=1be97463696c7291a3e1547614e96432b0bd3add <61631352a5b405c89be579de00903b72e6888aa4 || >=65f8b80053a1b2fd602daa6814e62d6fa90e5e9b <8865cd664484517703df5c18a965dc3227572b87 || >=65f8b80053a1b2fd602daa6814e62d6fa90e5e9b <a40c45268f4358207aa9c53764fed2e05f62986a || >=65f8b80053a1b2fd602daa6814e62d6fa90e5e9b <889ec86464d261f026f6c334040cfc6c58c99d58 || >=65f8b80053a1b2fd602daa6814e62d6fa90e5e9b <4902a5cba21aeaf91e6b29e20e0967a5f6abdcd9 || >=65f8b80053a1b2fd602daa6814e62d6fa90e5e9b <55ee6533c1db7f7656fa8dd19637f3f8b8c08dc5 || >=65f8b80053a1b2fd602daa6814e62d6fa90e5e9b <dbd4aea175ad3c46436acb251e817b4374628072 || >=65f8b80053a1b2fd602daa6814e62d6fa90e5e9b <54b6bd40898de7906acb2bccc9a96d1b8e6b4323 || 98953044b3cdb2cb7d82e7365b659e2ed4f4ca4d || af8ecc8d20e72130771cc076bce7fcf17ccda6c4 || c6fac5cf5a5098732623bcd00a8a3eb9f5465144 || 96fa141fa295ae9428da73c56c9852053b575c04 || >=5.10.163 <5.10.267 || >=5.15.61 <5.15.218 || >=4.19.270 <4.20 || >=5.4.229 <5.5 || >=5.18.18 <5.19 || >=5.19.2 <5.20 | 119a2f053242ed75bdd2ebc95baf3ae7db6ccacf, 61631352a5b405c89be579de00903b72e6888aa4, 8865cd664484517703df5c18a965dc3227572b87, a40c45268f4358207aa9c53764fed2e05f62986a, 889ec86464d261f026f6c334040cfc6c58c99d58, 4902a5cba21aeaf91e6b29e20e0967a5f6abdcd9, 55ee6533c1db7f7656fa8dd19637f3f8b8c08dc5, dbd4aea175ad3c46436acb251e817b4374628072, 54b6bd40898de7906acb2bccc9a96d1b8e6b4323, 5.10.267, 5.15.218, 4.20, 5.5, 5.19, 5.20 |
| Linux/Linuxgeneric | 6.0 | Not reported |
Published upstream
Sep 4, 2026
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Sep 4, 2026
Evidence: source:cvelist:source_dates:source-dates:recordFirst seen by HOL
Sep 4, 2026
In the Linux kernel, the following vulnerability has been resolved: ext4: stop retrying saturated xattr cache entries ext4_xattr_block_set() retries when a cache entry selected for reuse has a saturated reference count after taking the buffer lock. The retry returns to the mbcache lookup without making that entry ineligible, so it can select the same unusable entry indefinitely. A task spinning there can hold the parent directory's i_rwsem and leave concurrent rmdir callers blocked. Normally a reusable entry has a reference count below EXT4_XATTR_REFCOUNT_MAX because the count and MBE_REUSABLE_B are updated under the same buffer lock. A corrupted filesystem can violate that invariant. The syzbot reproducer reports allocator and xattr corruption before triggering this retry loop. Check the untrusted on-disk count before incrementing it, avoiding overflow, and clear MBE_REUSABLE_B when it is already saturated. The next lookup then skips the entry that was just proven unusable. This mirrors the normal transition at EXT4_XATTR_REFCOUNT_MAX; the release path marks the entry reusable again on the exact 1024-to-1023 transition. Using the same QEMU harness and guest parameters, current unpatched Linux hung in 6 of 8 420-second trials with the do_rmdir signature; representative NMI backtraces caught the owner spinning in ext4_xattr_block_set(). The patched kernel completed 28 of 28 trials without a hung-task report; the final twelve trials exercised the reviewed overflow-safe form of the change. syzbot's patch testing also completed without reproducing the hang.
Quoted source text, attributed separately from HOL analysis.