CVE-2026-45861

What it actually does

This is a local Linux kernel use-after-free flaw in the GFS2 filesystem quota handling code. During filesystem shutdown, GFS2 quota data objects may be freed while still linked on the LRU list; later, the GFS2 shrinker can traverse that stale list entry and access freed memory. Because the bug occurs in kernel space, successful exploitation could allow a local authenticated user with the ability to interact with affected GFS2 filesystem functionality to trigger memory corruption, potentially causing a kernel crash or enabling privilege escalation. The CVSS vector indicates local access, low attack complexity, low privileges required, no user interaction, and high confidentiality, integrity, and availability impact.

Why it matters to the business

Systems using affected Linux kernels with GFS2 enabled or mounted are at risk of local denial of service and, in a worst case, local privilege escalation to kernel-level control. The operational impact is highest for clustered Linux environments that rely on GFS2 for shared storage, where a kernel crash can disrupt workloads and clustered services. This issue is not currently listed in CISA KEV, is not known to be used in ransomware campaigns, has low EPSS, and has no public exploit maturity reported, so immediate emergency response is generally less urgent than for remotely exploitable or actively exploited vulnerabilities; however, kernel flaws with privilege-escalation potential should still be remediated through normal accelerated patch cycles.

How an attack unfolds

An attacker first needs local access to a vulnerable Linux system and enough privileges to interact with GFS2-related filesystem behavior, typically in an environment where GFS2 is enabled, mounted, or available for use. The attacker attempts to cause GFS2 quota data objects to be freed during filesystem shutdown or teardown while those objects remain on the LRU list. When memory pressure or shrinker activity later causes gfs2_qd_shrink_scan to walk the LRU list, the kernel may dereference an object that has already been freed. A reliable exploit would need to shape kernel heap state so that the freed memory is reused in an attacker-influenced way, converting the use-after-free into controlled memory corruption. Less sophisticated attempts may simply trigger a kernel oops, panic, or service outage. There is currently no indication from the provided intelligence that this vulnerability is being exploited in the wild or by named threat actors.

How to fix it

Upgrade to a Linux kernel version that includes the upstream GFS2 fix that removes quota data objects from the LRU list before freeing them in qd_put(). Because no exact fixed package versions were provided, use the relevant distribution or vendor advisory for the deployed kernel stream and install the first kernel build that contains the fix for CVE-2026-45861. After updating the kernel package, reboot into the patched kernel; installing the package alone is not sufficient if the host continues running the older kernel. Where immediate patching is not possible, reduce exposure by disabling or avoiding GFS2 on systems that do not require it, unmounting unused GFS2 filesystems, restricting local shell access, limiting administrative ability to mount or manipulate clustered filesystems, and applying standard hardening controls such as least privilege and kernel crash containment. Mitigations should be treated as temporary because the underlying memory-safety defect is in kernel code.

How to confirm the fix worked

Confirm the running kernel, not just the installed kernel package, is updated to a vendor build that contains the GFS2 qd_put LRU-removal fix. Validate exposure by checking whether the GFS2 module is loaded, whether GFS2 filesystems are mounted, and whether kernel configuration includes GFS2 support. On Linux systems, useful checks include reviewing `uname -r`, package manager kernel versions, `lsmod | grep gfs2`, `/proc/filesystems`, and current mounts for `gfs2`. Confirm remediation by booting into the fixed kernel and verifying that GFS2 shutdown, unmount, and quota-related operations no longer produce kernel warnings, KASAN reports, slab use-after-free messages, or crashes referencing `qd_put` or `gfs2_qd_shrink_scan`. For fleet validation, compare running kernel versions against vendor advisory data rather than relying only on upstream version numbers, because distributions may backport the fix.

Typical attack path

1. Gain local authenticated access to a Linux system running an affected kernel.
2. Confirm that GFS2 support is present and that GFS2 filesystem functionality can be reached or exercised.
3. Trigger GFS2 quota object allocation and teardown paths, especially filesystem shutdown or unmount behavior related to quota data objects.
4. Induce memory pressure or shrinker activity so gfs2_qd_shrink_scan processes stale LRU entries.
5. Exploit the resulting use-after-free to crash the kernel or attempt controlled kernel memory corruption.
6. If exploitation is reliable, escalate privileges or execute code with kernel-level control.

How to detect it

Detection should focus on evidence of triggering rather than network indicators, because this is a local kernel memory-corruption issue. Review kernel logs, system journal data, crash dumps, kdump/vmcore artifacts, hypervisor reset events, and endpoint telemetry for kernel oops, panic, KASAN, slab allocator, or general protection fault messages involving GFS2 quota handling. Important log sources include `journalctl -k`, `/var/log/kern.log`, `/var/log/messages`, `/var/log/syslog`, `dmesg`, `kdump` output, and crash analysis from `vmcore` files. Look for stack traces or warnings referencing `qd_put`, `gfs2_qd_shrink_scan`, GFS2 quota data, LRU list corruption, `slab-use-after-free`, `use-after-free`, or shrinker activity. Also correlate suspicious local user activity around mounting, unmounting, or manipulating GFS2 filesystems shortly before kernel crashes or reboots. There are no reliable remote network IOCs for this vulnerability, and absence of logs does not prove absence of exploitation because kernel crashes may truncate logs unless persistent journaling or crash dumping is enabled.

• slab-use-after-free
• use-after-free in qd_put
• qd_put
• gfs2_qd_shrink_scan
• gfs2_qd_shrink_count
• gfs2_quota
• GFS2
• gfs2
• LRU list corruption
• list_del corruption
• BUG: KASAN: slab-use-after-free
• BUG: unable to handle kernel paging request
• general protection fault
• kernel BUG
• kernel panic
• Oops:
• /var/crash
• /var/lib/systemd/coredump
• /proc/filesystems
• /sys/module/gfs2

What your security team should do

• Prioritize patching Linux systems that run GFS2, clustered storage, shared filesystems, or workloads where a kernel crash would cause material service disruption.
• Inventory systems with GFS2 enabled by checking loaded modules, mounted filesystem types, and kernel package versions.
• Schedule kernel updates and reboots through the normal accelerated kernel patch process, ensuring systems actually boot into the fixed kernel.
• Temporarily disable or avoid GFS2 on systems where it is not required until patched.
• Restrict local interactive access and administrative filesystem operations on affected systems, especially access that could mount, unmount, or exercise GFS2 quota paths.
• Monitor kernel logs for use-after-free, slab corruption, KASAN, oops, panic, or GFS2 shrinker messages that may indicate attempted triggering or instability.
• Because this is not KEV-listed, has low EPSS, and has no reported public exploit maturity, prioritize based on local exposure to GFS2 and business criticality rather than treating all Linux systems equally.