CVE-2026-98079: btrfs: zstd: fix lost wakeup when waiting for a workspace
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 zstdgetworkspace() even though a workspace is free. When zstdallocworkspace() fails, the task is queued on zwsm->wait and schedules unconditionally, never re-testing the pool. zstdputworkspace() publishes the workspace and then calls condwakeup(), which only wakes when a sleeper is already visible, so a workspace returned between the failed allocation and preparetowait() wakes nobody. The window is wide: zstdallocworkspace() 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 TASKUNINTERRUPTIBLE until some other task happens to return one. Re-check the pool after preparetowait() has published the waiter, and use the workspace if one turned up.
Affected Software
Event History
Frequently Asked Questions
What conditions are required for the stall to occur?
A writer must be waiting in zstd_get_workspace() after zstd_alloc_workspace() fails. A workspace must then be returned during the interval before the waiting task has made itself visible, causing the wakeup to be missed.
What is the operational impact of a missed wakeup?
The affected writer can remain in TASK_UNINTERRUPTIBLE indefinitely, despite a workspace being available. It may resume only if another task later returns a workspace and generates another wakeup.
How can this condition be recognized on an affected system?
A writer may be stuck in zstd_get_workspace() in an uninterruptible sleep while a Zstandard workspace is free. The issue is specifically associated with a failed workspace allocation and a lost wakeup from zstd_put_workspace().
Why is the timing window significant?
The allocation path uses kvmalloc() and can enter reclaim, making the interval between allocation failure and waiter setup relatively wide. The fallback maximum-level workspace is deliberately retained and is the workspace that waiters depend on for the wakeup.