CVE-2026-45961

What it actually does

This is a local Linux kernel denial-of-service vulnerability in the GFS2 filesystem mount/read-write transition error paths. If GFS2 initialization reaches specific failure states, the kernel can leak resources: kernel thread objects created for GFS2 log and quota handling, and an 8192-byte quota bitmap buffer. Repeated triggering can consume kernel memory and task-related resources, potentially degrading system stability or causing availability loss. The issue does not provide code execution, privilege escalation, or data disclosure based on the available description; the impact is availability-focused.

Why it matters to the business

Systems that use or allow mounting of GFS2 filesystems could suffer service instability or outages if a local user or process can repeatedly trigger failed GFS2 mount or read-write transition attempts. This is most relevant for clustered Linux environments, shared storage platforms, virtualization hosts, and systems where untrusted users can initiate mounts or influence filesystem images. The vulnerability is not listed in CISA KEV, has low EPSS, and no known mature public exploit is reported, so broad internet-scale exploitation is unlikely; however, availability-sensitive Linux infrastructure using GFS2 should still prioritize routine kernel updates.

How an attack unfolds

An attacker needs local access with enough privileges or delegated capability to cause GFS2 mount operations or transitions to read-write mode. They prepare or use conditions that make GFS2 initialization partially succeed and then fail, such as triggering failure after GFS2 kernel threads are initialized or after quota initialization occurs. Because the vulnerable error paths do not consistently clean up those resources, each failed attempt leaves kernel objects or quota bitmap memory allocated. By repeating the operation, the attacker can gradually increase unreclaimed kernel memory and related resource pressure until the host becomes degraded, unstable, or unavailable. Practical exploitation depends on whether the attacker can mount GFS2 filesystems or otherwise exercise the affected kernel paths; on many systems this requires elevated local privileges or access to a service that performs mounts on behalf of users.

How to fix it

Upgrade to a Linux kernel version that includes the upstream GFS2 fixes for cleanup in gfs2_fill_super() and gfs2_make_fs_rw(). Where vendor kernels are used, apply the relevant distribution security or stable kernel update rather than relying only on upstream version numbers. No exact fixed package versions were provided in the input, so administrators should consult their Linux distribution advisories for the corrected kernel build. If immediate patching is not possible, reduce exposure by limiting local users who can perform mounts, disabling or unloading GFS2 where it is not required, blocking untrusted filesystem images, and ensuring only trusted administrative automation can mount clustered filesystems.

How to confirm the fix worked

Confirm the running kernel package includes the vendor fix for the GFS2 memory leak in the gfs2_fill_super error path and gfs2_make_fs_rw quota cleanup path. Validate with distribution tooling such as package changelogs, vendor CVE trackers, kernel advisory metadata, or source-level confirmation that gfs2_destroy_threads() is called on the relevant fail_per_node path and quota cleanup is performed on gfs2_make_fs_rw() withdrawal/error handling. On systems where GFS2 is not needed, verify the module is absent, blacklisted, or not loaded. Operationally, confirm there are no unexpected GFS2 mounts, no repeated failed GFS2 mount attempts, and no unexplained growth in kernel memory usage after mount failures.

Typical attack path

1. Gain local access to a Linux system running an affected kernel with GFS2 support available.
2. Obtain the ability to initiate or influence GFS2 filesystem mount or read-write transition operations.
3. Craft or arrange a GFS2 mount scenario that reaches the vulnerable error path after thread initialization or quota initialization succeeds.
4. Repeatedly trigger failed GFS2 initialization or read-write transition attempts.
5. Accumulate leaked kernel resources over time.
6. Cause memory pressure, kernel instability, service degradation, or a denial of service.

How to detect it

Look for evidence of repeated failed GFS2 mount or read-write transition attempts followed by resource pressure. Useful sources include kernel logs, system journal logs, audit logs for mount syscalls, sudo logs, shell history where available, EDR process telemetry, and system performance metrics for kernel memory, slab usage, task counts, and out-of-memory events. Search for GFS2-related mount failures, filesystem withdrawal messages, quota initialization errors, and recurring mount commands targeting type gfs2. Because the vulnerability is a memory leak rather than a code-execution flaw, there may be no unique post-exploitation artifact; detection should focus on behavioral patterns: repeated GFS2 failures from the same user/process, unexplained kernel memory growth after those failures, hung services, OOM killer activity, or node instability in a cluster. If kernel memory debugging tools are enabled, look for leaked allocations with stack traces involving copy_process, kthread_create_on_node, init_threads, gfs2_fill_super, gfs2_quota_init, or gfs2_make_fs_rw.

• gfs2_fill_super
• gfs2_make_fs_rw
• gfs2_quota_init
• gfs2_freeze_lock_shared
• init_threads
• gfs2_destroy_threads
• kthread_create_on_node
• copy_process
• mount -t gfs2
• type=gfs2
• GFS2
• gfs2:
• filesystem withdrawn
• quota init
• Out of memory
• oom-killer
• unreferenced object
• kmemleak

What your security team should do

• Inventory Linux systems with GFS2 enabled, loaded, or in use, prioritizing clustered filesystems and shared-storage infrastructure.
• Apply vendor kernel updates that include the GFS2 cleanup fixes; schedule reboots where required for the new kernel to take effect.
• Restrict mount capabilities to trusted administrators and remove unnecessary sudo, container, or automation paths that allow users to mount arbitrary filesystems.
• Disable or blacklist the gfs2 kernel module on systems that do not require GFS2.
• Monitor for repeated failed GFS2 mount attempts, abnormal kernel memory growth, and kernel log messages associated with GFS2 withdrawal or mount failures.
• Treat exploitation likelihood as currently low because there is no KEV listing, no reported ransomware use, low EPSS, and no known exploit maturity, but prioritize remediation on availability-critical systems.