CVE-2026-89567

What it actually does

The jbd2 shrinker fails to decrement its scan budget for busy checkpoint buffers, allowing a single scan to traverse an entire checkpoint list while holding journal->j_list_lock and potentially causing soft lockups or RCU stalls on other CPUs.

Why it matters to the business

Systems may experience sudden unresponsiveness or kernel stalls under memory pressure or heavy journaling workloads, leading to degraded service availability and possible unplanned reboots; low exploit likelihood reduces immediate risk but does not eliminate operational exposure in large-scale Linux deployments.

How an attack unfolds

An attacker with local access crafts a workload that creates large checkpoint transactions dominated by busy buffers, then triggers the shrinker repeatedly to force prolonged lock contention and induce stalls or crashes without requiring network access or elevated privileges beyond standard user context.

How to fix it

Update the Linux kernel to a version containing the bound shrinker scan fix in jbd2; apply the change that passes nr_to_scan into journal_shrink_one_cp_list and decrements for every examined buffer.

How to confirm the fix worked

Confirm the presence of the upstream commit that restores scan-budget semantics in journal_shrink_one_cp_list; run targeted stress tests exercising checkpoint lists under memory pressure and verify absence of excessive j_list_lock hold times or stalls.

Typical attack path

1. Obtain local unprivileged access on a Linux system using jbd2 journaling.
2. Generate filesystem activity that produces checkpoint transactions containing mostly pinned buffers.
3. Induce memory pressure to activate the jbd2 shrinker.
4. Observe or trigger lock contention leading to soft lockups or RCU stalls.

How to detect it

Review kernel logs for repeated soft lockup or RCU stall entries mentioning j_list_lock or jbd2 shrinker activity; correlate with periods of high memory pressure and large checkpoint transactions.

What your security team should do

• Prioritize kernel updates on systems with heavy journaling or memory-constrained workloads.
• Monitor kernel logs for soft lockup and RCU stall messages referencing j_list_lock.
• Apply the fix in the next scheduled maintenance window given low EPSS and absence from KEV.