CVE-2026-45984

What it actually does

This is a Linux kernel use-after-free in the GFS2 filesystem inline-data write path. During an inline write, GFS2 stores a pointer to inode metadata buffer data in the iomap structure, then releases the underlying buffer head too early. If the buffer is reclaimed before the write completes, the kernel later writes through a stale pointer in iomap_write_end_inline(). In practical terms, a local user who can write to a mounted GFS2 filesystem may be able to trigger kernel memory corruption, causing a denial of service and, depending on allocator state and exploit development, potentially local privilege escalation or kernel data exposure.

Why it matters to the business

Systems using GFS2, especially clustered Linux environments, may be exposed to local attacks that can crash nodes or compromise host integrity. Because GFS2 is commonly used for shared storage and high-availability workloads, exploitation could disrupt multiple services that depend on the same cluster filesystem. The issue is not currently listed in CISA KEV, has no known public exploit maturity in the provided data, and has a low EPSS score, so urgency is highest for systems where untrusted or semi-trusted users can write to GFS2 mounts.

How an attack unfolds

An attacker first needs local access or the ability to cause writes to a mounted GFS2 filesystem. They then perform filesystem operations that exercise the inline data write path for a GFS2 inode. In the vulnerable path, gfs2_iomap_begin() reads inode metadata into a buffer head and assigns iomap->inline_data to memory inside that buffer. The function then releases the metapath, which can drop the buffer reference and allow the page to be reclaimed. If memory pressure or normal kernel reclaim frees that page before write completion, iomap_write_end_inline() later copies data into the stale inline_data pointer. This results in a use-after-free write in kernel memory. Most realistic outcomes are kernel warnings, KASAN reports on instrumented kernels, filesystem instability, or a kernel crash; with sufficient heap shaping, a capable local attacker may attempt to turn the memory corruption into privilege escalation.

How to fix it

Upgrade to a Linux kernel version that includes the GFS2 fix for retaining the buffer head until the iomap operation completes. The fix changes GFS2 to store the buffer head in iomap->private, take an additional reference with get_bh() in gfs2_iomap_begin(), and release it in gfs2_iomap_end(). No exact fixed package versions were provided, so use the fixed kernel packages from the relevant Linux distribution or vendor advisory. If immediate patching is not possible, reduce exposure by limiting local shell access, restricting write access to GFS2 mounts, disabling or unmounting GFS2 where not required, avoiding use of GFS2 for workloads reachable by untrusted users, and applying standard kernel hardening and workload isolation controls. Reboot into the patched kernel after installation; simply installing kernel packages is not sufficient if the running kernel remains vulnerable.

How to confirm the fix worked

Confirm the running kernel, not just the installed package, is updated to a vendor build containing the GFS2 use-after-free fix. Validate whether GFS2 is in use by checking loaded modules, mounted filesystems, and cluster storage configurations. Review vendor changelogs or kernel source for the presence of the fix that keeps a referenced buffer head through gfs2_iomap_begin() and releases it in gfs2_iomap_end(). After remediation, reboot and verify the active kernel version with standard OS tooling. For exposure validation, identify hosts with the gfs2 module loaded or GFS2 filesystems mounted and determine whether untrusted users or services can write to those mounts. Avoid attempting to reproduce the bug on production systems because the expected failure mode can include kernel memory corruption or node crash.

Typical attack path

1. Obtain local code execution, shell access, container escape-adjacent filesystem access, or another path to issue writes to a mounted GFS2 filesystem.
2. Identify or create files stored as inline data on the GFS2 filesystem.
3. Trigger write operations that invoke the GFS2 iomap inline data write path.
4. Increase reliability by creating timing or memory-pressure conditions that allow the released buffer page to be reclaimed before write completion.
5. Cause iomap_write_end_inline() to write through a stale pointer, producing kernel memory corruption.
6. Leverage the outcome for denial of service through kernel crash or, if exploit primitives are developed, attempt local privilege escalation.

How to detect it

Look for evidence of attempted or successful triggering in kernel and system logs. Primary sources include journalctl -k, dmesg, /var/log/kern.log, /var/log/messages, crash dumps, kdump/vmcore analysis, kernel oops reports, audit logs for local user activity, and filesystem activity around GFS2 mounts. On KASAN or debug kernels, search for explicit use-after-free reports involving iomap_write_end_inline(), gfs2_iomap_begin(), gfs2_iomap_end(), gfs2_meta_inode_buffer(), release_metapath(), brelse(), or memcpy() into inline data. On production kernels without sanitizers, indicators may be less direct: kernel oops, BUG/WARNING traces, page faults in GFS2 or iomap code, general protection faults, slab corruption, filesystem withdrawal messages, or unexplained node panic while writing to GFS2. Correlate crashes with local users, containers, scheduled jobs, or services writing small files or metadata-heavy workloads to GFS2 mounts. There are no reliable network indicators because exploitation is local and filesystem-operation based.

• KASAN: use-after-free
• BUG: KASAN: use-after-free
• Read of size
• Write of size
• iomap_write_end_inline
• gfs2_iomap_begin
• gfs2_iomap_end
• gfs2_meta_inode_buffer
• release_metapath
• brelse
• gfs2
• GFS2
• kernel BUG
• kernel oops
• general protection fault
• Unable to handle kernel paging request
• slab-use-after-free
• use-after-free in iomap_write_end_inline
• use-after-free in gfs2_iomap_begin
• memcpy
• gfs2: fsid=

What your security team should do

• Prioritize patching Linux systems that mount GFS2 filesystems and allow local users, containers, batch jobs, or application services to write to those mounts.
• Inventory GFS2 usage across servers and clusters using mount data, loaded kernel modules, storage configuration, and configuration management records.
• Apply vendor kernel updates and reboot affected systems into the fixed kernel; schedule coordinated maintenance for clustered GFS2 deployments to avoid service disruption.
• Until patched, restrict write permissions on GFS2 mounts to trusted service accounts and administrators only.
• Monitor kernel logs for GFS2, iomap, buffer head, slab, page allocation, KASAN, BUG, WARNING, oops, panic, or use-after-free messages.
• Treat unexplained kernel crashes on GFS2 nodes as potentially security-relevant, especially if preceded by local user activity or unusual filesystem writes.
• Because exploit maturity is currently reported as none and EPSS is low, balance urgency against operational risk, but do not defer patching on multi-user or shared-storage systems.