CVE-2025-39782

What it actually does

Missing cond_resched() call in jbd2_log_do_checkpoint() allows prolonged spinlock contention on j_list_lock during checkpoint processing, causing watchdog softlockups when __flush_batch() and wait_on_buffer() do not yield the CPU.

Why it matters to the business

Heavy write workloads on affected Linux systems can trigger prolonged CPU unresponsiveness and system hangs, disrupting operations on servers and container hosts using the impacted kernel and CUDA packages; prevalence across many downstream images increases exposure.

How an attack unfolds

An attacker or workload triggers repeated journal checkpointing and writeback operations that contend on j_list_lock; without explicit rescheduling, the kworker thread spins for extended periods leading to softlockup detection, as observed in container-optimized environments under load from actors such as VMSCAPE.

How to fix it

Update to fixed kernel commit f683d611518d30334813eecf9a8c687453e2800e or later; for MinimOS CUDA packages upgrade to version 12.9.1-r7 or newer for cuda-toolkit-12, cuda-ldconfig-12, cuda-compat-12, cuda-cudart-12, libcublas-12, libcufft-12, libcufile-12, libcusolver-12, libcusparse-12, libnpp-12, libnvjpeg-12, cuda-nvrtc-12, libnvjitlink-12, libnvfatbin-12, cuda-nvtx-12, cuda-nvtx-dev-12, cuda-opencl-12, and libcurand-12.

How to confirm the fix worked

Confirm kernel contains the cond_resched() addition in jbd2_log_do_checkpoint(); verify package versions match the listed fixed releases; reproduce writeback workload and ensure no softlockup messages appear in dmesg.

Typical attack path

1. Trigger filesystem write activity that starts a transaction requiring checkpoint space
2. Cause jbd2_log_do_checkpoint() to enter its processing loop while contending for j_list_lock
3. Avoid sleeping in __flush_batch() or wait_on_buffer() so need_resched() remains false
4. Sustain lock hold time long enough for the softlockup watchdog to fire

How to detect it

Search kernel logs for softlockup messages referencing jbd2_log_do_checkpoint and kworker threads; examine dmesg or journalctl output around writeback activity for CPU stuck warnings; correlate with high I/O workloads on ext4 filesystems.

What your security team should do

• Prioritize kernel and CUDA package updates on all affected systems before the next maintenance window
• Monitor for softlockup watchdog messages on systems performing heavy ext4/journaled I/O
• Apply workload throttling or I/O scheduling changes as temporary mitigation if immediate patching is delayed