Answer in brief
CVE-2026-98079 records a Unknown severity vulnerability in btrfs: zstd: fix lost wakeup when waiting for a workspace. 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 | >=3f93aef535c8ea03e40cd8acf0753b3e6ed33e96 <d8f57049521948df5f50797141472fbbed3b0723 || >=3f93aef535c8ea03e40cd8acf0753b3e6ed33e96 <0de9f31d447ae71ab08c7850a321682f8d2907c3 || >=3f93aef535c8ea03e40cd8acf0753b3e6ed33e96 <2acb9f3d1cc8f65dc81ed55e238cbf8e5b60bff7 | d8f57049521948df5f50797141472fbbed3b0723, 0de9f31d447ae71ab08c7850a321682f8d2907c3, 2acb9f3d1cc8f65dc81ed55e238cbf8e5b60bff7 |
| Linux/Linuxgeneric | 5.1 | Not reported |
Published upstream
Sep 25, 2026
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Sep 25, 2026
Evidence: source:cvelist:source_dates:source-dates:recordFirst seen by HOL
Sep 25, 2026
In the Linux kernel, the following vulnerability has been resolved: btrfs: zstd: fix lost wakeup when waiting for a workspace A writer can sleep forever in zstd_get_workspace() even though a workspace is free. When zstd_alloc_workspace() fails, the task is queued on zwsm->wait and schedules unconditionally, never re-testing the pool. zstd_put_workspace() publishes the workspace and then calls cond_wake_up(), which only wakes when a sleeper is already visible, so a workspace returned between the failed allocation and prepare_to_wait() wakes nobody. The window is wide: zstd_alloc_workspace() goes through kvmalloc() and may enter reclaim. Only a max level workspace triggers the wakeup and one is deliberately kept allocated as the fallback every waiter waits for, so once its wakeup is lost the writer stays in TASK_UNINTERRUPTIBLE until some other task happens to return one. Re-check the pool after prepare_to_wait() has published the waiter, and use the workspace if one turned up.
Quoted source text, attributed separately from HOL analysis.