CVE-2025-39842

What it actually does

Null pointer dereference in ocfs2 filesystem during volume dismount: ocfs2_delete_osb calls into __ocfs2_free_slot_info and ocfs2_clear_inode after ocfs2_journal_shutdown has already set osb->journal to NULL, causing jbd2_journal_release_jbd_inode to dereference a null j_journal pointer.

Why it matters to the business

Local denial-of-service on Linux systems using the ocfs2 clustered filesystem; unmount operations can trigger kernel crashes, disrupting storage access and requiring reboots with potential data unavailability for workloads depending on ocfs2 volumes.

How an attack unfolds

An attacker with local access triggers ocfs2 volume dismount in a sequence that reaches ocfs2_free_slot_info after journal shutdown; the missing journal pointer check leads to a null dereference and crash. Related Linux kernel privilege-escalation techniques from groups such as VMSCAPE have been observed in similar container-optimized OS environments.

How to fix it

Apply the upstream fix commit 42c415c53ad2065088cc411d08925effa5b3d255 or later stable kernels containing the added osb->journal NULL checks before ocfs2_delete_osb. Rebuild and deploy the patched kernel across all affected systems; test ocfs2 mount/unmount paths in staging before production rollout.

How to confirm the fix worked

Confirm the running kernel contains commit 42c415c53ad2065088cc411d08925effa5b3d255 via git log or kernel version string; attempt controlled ocfs2 volume dismounts and verify absence of null-pointer call traces in dmesg; monitor for the fixed execution path in ocfs2_dismount_volume.

Typical attack path

1. Obtain local user access on a system mounting ocfs2 volumes
2. Trigger or force ocfs2_dismount_volume under timing that executes ocfs2_delete_osb after journal shutdown
3. Reach evict -> ocfs2_evict_inode -> ocfs2_clear_inode with osb->journal already NULL
4. Invoke jbd2_journal_release_jbd_inode on the null pointer causing kernel oops/panic

How to detect it

Search kernel logs and crash dumps for call traces containing ocfs2_dismount_volume, ocfs2_delete_osb, __ocfs2_free_slot_info, ocfs2_evict_inode, and jbd2_journal_release_jbd_inode; correlate with ocfs2 volume unmount events and unexpected kernel panics on systems running vulnerable kernels.

• ocfs2_dismount_volume->ocfs2_delete_osb->ocfs2_free_slot_info
• jbd2_journal_release_jbd_inode(osb->journal->j_journal
• ocfs2_clear_inode
• evict() called after journal shutdown

What your security team should do

• Prioritize patching all ocfs2-using systems within the next maintenance window given the 403-day exposure window
• Add kernel oops monitoring and ocfs2 unmount logging to detection rules
• Restrict local access to systems hosting ocfs2 volumes until patches are applied
• Review downstream dependent packages and rebuild any custom kernels that include ocfs2