CVE-2025-39782 in Linux
Summary
by MITRE • 09/11/2025
In the Linux kernel, the following vulnerability has been resolved:
jbd2: prevent softlockup in jbd2_log_do_checkpoint()
Both jbd2_log_do_checkpoint() and jbd2_journal_shrink_checkpoint_list() periodically release j_list_lock after processing a batch of buffers to avoid long hold times on the j_list_lock. However, since both functions contend for j_list_lock, the combined time spent waiting and processing can be significant.
jbd2_journal_shrink_checkpoint_list() explicitly calls cond_resched() when need_resched() is true to avoid softlockups during prolonged operations. But jbd2_log_do_checkpoint() only exits its loop when need_resched() is true, relying on potentially sleeping functions like __flush_batch() or wait_on_buffer() to trigger rescheduling. If those functions do not sleep, the kernel may hit a softlockup.
watchdog: BUG: soft lockup - CPU#3 stuck for 156s! [kworker/u129:2:373]
CPU: 3 PID: 373 Comm: kworker/u129:2 Kdump: loaded Not tainted 6.6.0+ #10 Hardware name: Huawei TaiShan 2280 /BC11SPCD, BIOS 1.27 06/13/2017 Workqueue: writeback wb_workfn (flush-7:2) pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : native_queued_spin_lock_slowpath+0x358/0x418 lr : jbd2_log_do_checkpoint+0x31c/0x438 [jbd2]
Call trace: native_queued_spin_lock_slowpath+0x358/0x418 jbd2_log_do_checkpoint+0x31c/0x438 [jbd2]
__jbd2_log_wait_for_space+0xfc/0x2f8 [jbd2]
add_transaction_credits+0x3bc/0x418 [jbd2]
start_this_handle+0xf8/0x560 [jbd2]
jbd2__journal_start+0x118/0x228 [jbd2]
__ext4_journal_start_sb+0x110/0x188 [ext4]
ext4_do_writepages+0x3dc/0x740 [ext4]
ext4_writepages+0xa4/0x190 [ext4]
do_writepages+0x94/0x228 __writeback_single_inode+0x48/0x318 writeback_sb_inodes+0x204/0x590 __writeback_inodes_wb+0x54/0xf8 wb_writeback+0x2cc/0x3d8 wb_do_writeback+0x2e0/0x2f8 wb_workfn+0x80/0x2a8 process_one_work+0x178/0x3e8 worker_thread+0x234/0x3b8 kthread+0xf0/0x108 ret_from_fork+0x10/0x20
So explicitly call cond_resched() in jbd2_log_do_checkpoint() to avoid softlockup.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 01/16/2026
The vulnerability described in CVE-2025-39782 resides within the Linux kernel's journaling subsystem, specifically affecting the jbd2 module responsible for managing journaling operations in filesystems like ext4. This issue manifests as a potential soft lockup condition during checkpoint processing, which can lead to system unresponsiveness and denial of service. The flaw occurs when the jbd2_log_do_checkpoint() function enters an extended loop without yielding control back to the scheduler, causing the system to become unresponsive for extended periods.
The technical root cause involves the jbd2_journal_shrink_checkpoint_list() function properly implementing cond_resched() calls to prevent long lock hold times, while jbd2_log_do_checkpoint() fails to do so. Both functions compete for the j_list_lock, creating a scenario where prolonged processing can occur without yielding to the scheduler. The jbd2_log_do_checkpoint() function only exits its loop when need_resched() is true, relying on potentially sleeping functions like __flush_batch() or wait_on_buffer() to trigger rescheduling. When these functions do not sleep, the kernel can remain stuck in the checkpoint processing loop, leading to a soft lockup condition.
The operational impact of this vulnerability is significant as it can cause system instability during high I/O workloads or when filesystem checkpoint operations are intensive. The watchdog subsystem detects this condition with messages indicating CPU starvation, where CPU#3 becomes stuck for over 150 seconds, demonstrating the severity of the lockup. The call trace shows the function chain leading to the lockup, starting from native_queued_spin_lock_slowpath through jbd2_log_do_checkpoint to __jbd2_log_wait_for_space, highlighting the specific kernel components involved in the problematic execution path.
The vulnerability aligns with CWE-667, which addresses improper locking mechanisms, and maps to ATT&CK technique T1490 for denial of service through resource exhaustion. The fix implemented involves explicitly calling cond_resched() within jbd2_log_do_checkpoint() to ensure proper scheduler yielding during long-running operations. This approach follows established kernel best practices for preventing soft lockups and maintains system responsiveness during intensive journaling operations. The mitigation strategy directly addresses the race condition between checkpoint processing functions and ensures that the kernel scheduler receives adequate opportunities to process other tasks, preventing the accumulation of lock hold times that could lead to system unresponsiveness.