CVE-2024-42077

What it actually does

Insufficient transaction credit estimation in ocfs2_dio_end_io_write() for arbitrarily large direct IO containing many single-block extents leads to exhaustion of jbd2 handle credits during extent tree manipulations, triggering WARN_ON and forced OCFS2 abort with kernel panic.

Why it matters to the business

Linux systems using the OCFS2 filesystem experience unexpected kernel panics and forced aborts during direct IO writes on fragmented volumes, resulting in unplanned downtime, potential service disruption, and operational instability until the kernel is updated.

How an attack unfolds

An attacker with local access performs large direct writes to a heavily fragmented OCFS2 filesystem containing many single-block extents; the write path calls ocfs2_mark_extent_written() repeatedly without extending the transaction, exhausting credits and forcing an OCFS2 abort and panic. Generic Linux kernel threat actors may leverage similar uninitialized or resource issues in targeted campaigns, though no specific actors are tied to this flaw.

How to fix it

Upgrade the Linux kernel to a version containing commit 2dcd0af568b0cf583645c8a317dd12e344b1c72a or later that ensures sufficient transaction credits before each ocfs2_mark_extent_written() call. Reboot affected systems after applying the fixed kernel package.

How to confirm the fix worked

Confirm the running kernel contains commit 2dcd0af568b0cf583645c8a317dd12e344b1c72a or equivalent backport; test direct IO writes on fragmented OCFS2 volumes and verify absence of jbd2_handle_buffer_credits warnings or OCFS2 aborts in dmesg.

Typical attack path

1. Obtain local shell or process execution on target Linux system
2. Identify or create a heavily fragmented OCFS2 volume
3. Issue large direct IO writes via generic_file_direct_write or aio_write paths
4. Trigger repeated single-block extent flag changes without transaction extension
5. Exhaust jbd2 transaction credits causing OCFS2 abort and kernel panic

How to detect it

Inspect kernel logs and dmesg for OCFS2 panic messages containing 'panic forced after error', 'ocfs2_journal_dirty', or 'jbd2_handle_buffer_credits' warnings; correlate with direct IO write activity on OCFS2 devices.

• Kernel panic - not syncing: OCFS2: (device
• panic forced after error
• ocfs2_handle_error
• __ocfs2_abort
• WARN_ON(jbd2_handle_buffer_credits(handle) <= 0)
• ocfs2_dio_end_io_write
• ocfs2_mark_extent_written

What your security team should do

• Prioritize kernel upgrade to the fixed version containing 2dcd0af568b0cf583645c8a317dd12e344b1c72a across all OCFS2 deployments
• Monitor dmesg and kernel logs for OCFS2 abort messages on production systems until patched
• Limit direct IO usage on fragmented OCFS2 filesystems as a temporary mitigation where feasible
• Review filesystem fragmentation status and perform defragmentation on critical volumes