CVE-2024-42079

What it actually does

NULL pointer dereference in gfs2_log_flush when sdp->sd_jdesc is dereferenced without checking during a race between glock work and unmount in the GFS2 filesystem.

Why it matters to the business

Systems using the GFS2 filesystem may experience kernel crashes and unexpected reboots during unmount operations, leading to service disruption and potential filesystem inconsistency on affected Linux deployments.

How an attack unfolds

An attacker with local access triggers concurrent glock work and filesystem unmount operations to hit the window where sd_jdesc is NULL, causing the kernel to dereference a null pointer and panic.

How to fix it

Upgrade the Linux kernel to a version containing commit c3c5cfa3170c0940bc66a142859caac07d19b9d6 or later that sets sd_jdesc to NULL under the log flush lock and adds the NULL check in gfs2_log_flush.

How to confirm the fix worked

Verify the running kernel includes the referenced commit, confirm GFS2 unmount and glock operations no longer trigger the dereference path, and review kernel build configuration for GFS2 support.

Typical attack path

1. Obtain local access on a system mounting a GFS2 filesystem
2. Initiate filesystem unmount while pending glock work is queued
3. Race condition leads gfs2_log_flush to dereference NULL sd_jdesc
4. Kernel panics due to memory corruption

How to detect it

Inspect kernel logs and dmesg output for NULL pointer dereference faults or oops traces mentioning gfs2_log_flush, gfs2_jindex_free, or glock_work_func during unmount activity.

• gfs2_log_flush
• NULL pointer dereference
• glock_work_func
• inode_go_sync

What your security team should do

• Prioritize kernel updates on all systems using GFS2 filesystems
• Monitor for kernel oops or panic reports referencing gfs2_log_flush
• Restrict local unmount privileges where possible until patched