CVE-2023-52448 - Kernel NULL Pointer Dereference in GFS2 (gfs2_rgrp_dump Exploit and Patch Analysis)

In early 2024, a Linux kernel bug was discovered in the GFS2 filesystem code that could crash the system with a NULL pointer dereference. This bug, tracked as CVE-2023-52448, was flagged by Syzkaller, a popular kernel fuzzing tool. The vulnerability arises from how GFS2 handles resource groups (rgrps) — an essential file system data structure.

In this post, you'll get an exclusive, plain-language walkthrough: what the bug is, how it happens, example code showing the vulnerable situation, how it's fixed, and how an attacker could use it. We wrap up with links to the original commit and advisories.

Background: GFS2 and Resource Groups

GFS2, or Global File System 2, is a clustered file system used in Linux. It lets multiple machines share access to the same storage device (think high-availability setups).

A "resource group descriptor" (rgd) is a structure in GFS2 managing a group of filesystem blocks. The function gfs2_rgrp_dump() prints information about these rgrps for debugging. This data structure is filled in partly by read_rindex_entry(), which sets up several pointers during its work.

The function read_rindex_entry() is responsible for loading a resource group (rgd).

- Part of this process sets up the pointer rd_rgl via a call that may fail. If it does fail, rd_rgl will remain NULL.

Later, gfs2_rgrp_dump() uses rd_rgl to print information without checking if it's NULL.

- If gfs2_rgrp_dump() is called with a rgd that has a NULL rd_rgl, the kernel tries to dereference a NULL pointer — instant kernel panic (system crash).

This opens up a Denial-of-Service vector, especially if a local attacker can trigger specific GFS2 operations.

Here is a simplified look at the problematic code (for illustration)

void gfs2_rgrp_dump(struct gfs2_rgrpd *rgd) {
    // ...other code...
    printk("Block number: %llu\n", rgd->rd_rgl->ai_addr); // No NULL pointer check!
    // ...other code...
}

If rgd->rd_rgl is NULL, the line above will dereference a NULL pointer, causing a kernel oops.

And this happens if the previous function failed

// In read_rindex_entry():
rgd->rd_rgl = create_gl(); // could fail, leaves rd_rgl as NULL

Discovery: Syzkaller, the kernel fuzzing tool

- Report: syzkaller issue (check upstream for ID)

The Patch (How It’s Fixed)

The maintainers added a NULL pointer check before accessing the possibly NULL pointer inside gfs2_rgrp_dump():

void gfs2_rgrp_dump(struct gfs2_rgrpd *rgd) {
    // ...other code...
    if (rgd->rd_rgl)
        printk("Block number: %llu\n", rgd->rd_rgl->ai_addr);
    else
        printk("Block number: unknown (rd_rgl is NULL)\n");
    // ...other code...
}

This simple check prevents the kernel from dereferencing a NULL pointer — avoiding the crash.

Reference:
- Linux Kernel Patch Commit

Exploit Details

While this bug doesn't allow arbitrary code execution, it is *very* useful for a local denial-of-service attack. Anyone with at least basic privileges to mount/mess with GFS2 filesystems could trigger it. All they'd need is to:

Then trigger gfs2_rgrp_dump() (possible via debugging tools or crafted operations)

If successful, the Linux kernel will panic and the system will go down.

A pseudocode "exploit" test case might look like

// Not production code; for illustrative purposes only!
int main() {
    struct gfs2_rgrpd rgd = {};
    rgd.rd_rgl = NULL; // Simulate failure
    
    gfs2_rgrp_dump(&rgd); // Kernel will crash if unpatched
    return ;
}

On an unpatched system, this would cause a kernel crash when gfs2_rgrp_dump() accesses rd_rgl.

Mitigation

This is a kernel bug. The only surefire fix is to *patch your kernel!* If you run GFS2 or allow untrusted users to access local block devices:

References & Resources

- Upstream Patch Commit
- Syzkaller Kernel Fuzzer
- CVE page (NVD) *(once available)*

Conclusion

CVE-2023-52448 is a great example of how fuzz testing tools like Syzkaller help catch subtle but dangerous bugs even in mature, critical code. If you're running a Linux system using GFS2, make sure you have the patch. As always, kernel crashes are *never* just annoying — they are a real threat in production and shared hosting environments.

Timeline

Published on: 02/22/2024 17:15:08 UTC
Last modified on: 03/18/2024 18:38:36 UTC