CVE-2024-49956

What it actually does

Double invocation of destroy_workqueue on the same GFS2 workqueue object during error paths in gfs2_fill_super leads to use-after-free or double-free conditions in kernel memory management.

Why it matters to the business

Linux systems using the GFS2 filesystem may experience unexpected kernel crashes or instability during mount failures, increasing downtime risk for storage-dependent workloads; prevalence in the Linux ecosystem amplifies exposure across servers and distributions.

How an attack unfolds

An attacker with local access triggers a failure condition in gfs2_fill_super (for example via malformed mount parameters or resource exhaustion) to reach the double destroy_workqueue path; listed threat actors in zero-day and kernel exploitation campaigns could chain this into broader memory corruption for denial of service or further kernel compromise.

How to fix it

Upgrade the Linux kernel to version 6.11.3 or apply the patch from commit a5336035728d77efd76306940d742a6f23debe68; for Rocky Linux 8 update openchange to 2.3-27.el8 and samba to 4.13.3-3.el8; verify workqueue pointer is cleared after first destroy and guarded on subsequent calls.

How to confirm the fix worked

Confirm kernel version is at least 6.11.3 or contains the referenced commit; review gfs2_gl_hash_clear and gfs2_fill_super for NULL checks on the workqueue pointer after destroy_workqueue.

Typical attack path

1. Obtain local access to a Linux system with GFS2 support
2. Craft conditions that cause gfs2_fill_super to fail after the first workqueue destroy
3. Trigger the subsequent code path that re-invokes destroy_workqueue
4. Exploit resulting memory corruption for denial of service or privilege escalation

How to detect it

Review kernel logs for repeated destroy_workqueue calls or GFS2 error paths around mount failures; search dmesg and syslog for workqueue-related warnings or oops messages tied to gfs2_gl_hash_clear; correlate with any listed kernel exploitation campaign indicators.

What your security team should do

• Prioritize kernel upgrades to 6.11.3 across all GFS2-using systems due to memory corruption family
• Monitor EPSS trend and threat actor activity for any increase in exploitation attempts
• Test patches in staging environments before broad deployment
• Restrict unprivileged local access where GFS2 mounts are possible until remediated