CVE-2026-98079
N/A
Summary
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.
Affected Software
| Vendor | Product | Version Range | Status |
|---|---|---|---|
| Linux | Linux | 3f93aef535c8ea03e40cd8acf0753b3e6ed33e96 < d8f57049521948df5f50797141472fbbed3b0723 | affected |
| Linux | Linux | 3f93aef535c8ea03e40cd8acf0753b3e6ed33e96 < 0de9f31d447ae71ab08c7850a321682f8d2907c3 | affected |
| Linux | Linux | 3f93aef535c8ea03e40cd8acf0753b3e6ed33e96 < 2acb9f3d1cc8f65dc81ed55e238cbf8e5b60bff7 | affected |
| Linux | Linux | 5.1 | affected |
| Linux | Linux | 0 < 5.1 | unaffected |
| Linux | Linux | 6.18.53 <= 6.18.* | unaffected |
| Linux | Linux | 7.2.7 <= 7.2.* | unaffected |
| Linux | Linux | 7.3-rc2 <= * | unaffected |
Weaknesses
References
- https://git.kernel.org/stable/c/d8f57049521948df5f50797141472fbbed3b0723
- https://git.kernel.org/stable/c/0de9f31d447ae71ab08c7850a321682f8d2907c3
- https://git.kernel.org/stable/c/2acb9f3d1cc8f65dc81ed55e238cbf8e5b60bff7
Feedback
Was this page helpful?
Glad to hear it! Please tell us how we can improve.
Sorry to hear that. Please tell us how we can improve.