CVE-2026-89566: jbd2: check need_resched() when skipping busy checkpoint buffers
In the Linux kernel, the following vulnerability has been resolved:
jbd2: check needresched() when skipping busy checkpoint buffers
journalshrinkonecplist() skips busy checkpoint buffers when called with JBD2SHRINKBUSYSKIP. The continue statement on this path also skips the needresched() check at the end of the loop body.
Consequently, when a checkpoint list contains mostly busy buffers, the shrinker can walk the entire list while holding journal->jlistlock, even when a reschedule has been requested. Large checkpoint lists under memory pressure can therefore cause long lock hold times and leave other CPUs spinning on jlistlock, resulting in soft lockups or RCU stalls.
Route the busy-buffer path through the needresched() check so that the shrinker can release jlistlock and reschedule promptly, restoring parity with the clean-buffer path, which already checks needresched(). This does not change which checkpoint buffers are eligible for removal.
Affected Software
Event History
Frequently Asked Questions
What systems are most likely to experience this issue?
Linux systems that can build large journal checkpoint lists and encounter memory pressure are the relevant exposure case. The problematic behavior is most pronounced when those lists contain mostly busy checkpoint buffers.
What conditions are needed to trigger the impact?
The journal shrinker must run with JBD2_SHRINK_BUSY_SKIP while processing a checkpoint list dominated by busy buffers, and a reschedule request must occur during the walk. Under those conditions, it can retain journal->j_list_lock for an extended period.
What is the operational impact if it is triggered?
Other CPUs can spin waiting for j_list_lock while the shrinker traverses the list. This can result in soft lockups or RCU stalls rather than changing which checkpoint buffers may be removed.
What changes in the resolved implementation?
Busy checkpoint buffers now pass through the need_resched() check instead of bypassing it with a continue statement. This allows the shrinker to release journal->j_list_lock and reschedule promptly.