CVE-2026-45984: Linux Kernel Use-After-Free Vulnerability

CVE-2026-45984 Overview

CVE-2026-45984 is a use-after-free vulnerability in the Linux kernel's GFS2 (Global File System 2) module. The flaw resides in the gfs2_iomap_begin() function, which prematurely releases the inline data buffer head (dibh) via release_metapath() while iomap->inline_data still points to dibh->b_data. When iomap_write_end_inline() later attempts to write to the inline data area, it accesses freed memory. The defect was identified through a syzbot KASAN report and corrected by storing dibh in iomap->private and incrementing its refcount with get_bh().

Critical Impact

Local attackers with the ability to trigger inline data writes on GFS2 filesystems can cause kernel memory corruption, potentially leading to denial of service or privilege escalation on affected systems.

Affected Products

• Linux kernel versions containing the GFS2 iomap inline data write path
• Distributions shipping vulnerable kernels with GFS2 support enabled
• Clustered storage environments using GFS2 as a shared filesystem

Discovery Timeline

• 2026-05-27 - CVE-2026-45984 published to NVD
• 2026-05-27 - Last updated in NVD database

Technical Details for CVE-2026-45984

Vulnerability Analysis

The vulnerability affects the GFS2 filesystem's inline data write path within the Linux kernel's iomap subsystem. GFS2 supports storing small file data inline within the inode block to avoid allocating a separate data block. The iomap framework coordinates the read-modify-write cycle for these inline operations.

In the vulnerable code path, gfs2_iomap_begin() reads inode metadata into a buffer head referenced by dibh, then assigns iomap->inline_data = dibh->b_data + sizeof(struct gfs2_dinode). The function subsequently calls release_metapath(), which invokes brelse(dibh) and drops the buffer head reference count to zero. The buffer head and its underlying page become eligible for reclamation.

When kswapd reclaims the page, the memory pointed to by iomap->inline_data is freed. Later, iomap_write_end_inline() performs a memcpy() into this dangling pointer, producing a use-after-free write that KASAN detects. The syzbot report observed the page being reclaimed approximately 39 milliseconds after release.

Root Cause

The root cause is a lifetime mismatch between the buffer head dibh and the iomap structure that depends on its data. The buffer head reference is dropped before the iomap operation completes, violating the invariant that the underlying memory must remain valid for the entire iomap transaction.

Attack Vector

Exploitation requires local access and the ability to perform write operations against a GFS2 filesystem. An attacker triggers inline data writes that drive the racy reclamation of the prematurely released buffer head. The condition is timing-sensitive; the original report relied on kswapd reclamation pressure to materialize the use-after-free. No public C reproducer accompanies the fix.

The vulnerability is described in prose because no verified exploit code is published. See the kernel commit faddeb8 for the corrected code path.

Detection Methods for CVE-2026-45984

Indicators of Compromise

• KASAN reports referencing use-after-free in iomap_write_end_inline or gfs2_iomap_begin
• Kernel oops or panic messages originating from the GFS2 module during file write operations
• Unexpected filesystem corruption on GFS2 volumes following heavy small-file write activity

Detection Strategies

• Enable KASAN on test kernels to surface use-after-free conditions in the iomap inline write path
• Audit running kernel versions across clustered storage nodes to identify hosts running unpatched GFS2 code
• Correlate dmesg output for GFS2-related crashes with workloads that produce small inline writes

Monitoring Recommendations

• Monitor kernel logs (/var/log/kern.log, journalctl -k) for GFS2 and KASAN error signatures
• Track kernel package versions across the fleet with configuration management tooling to flag drift from patched builds
• Alert on unexpected node reboots or filesystem remounts in GFS2 cluster environments

How to Mitigate CVE-2026-45984

Immediate Actions Required

• Apply the upstream kernel patches that take a buffer head reference in gfs2_iomap_begin() and release it in gfs2_iomap_end()
• Update to a stable kernel build that incorporates the GFS2 iomap fix from your distribution vendor
• Restrict local access to systems running GFS2 until patched kernels are deployed

Patch Information

The fix stores dibh in iomap->private and increments its refcount with get_bh() in gfs2_iomap_begin(). The buffer head is then released in gfs2_iomap_end() after the inline write completes. The patch is available across multiple stable branches via the following commits:

• Kernel Git Commit 1403989
• Kernel Git Commit 1cae1ba
• Kernel Git Commit 6d76feb
• Kernel Git Commit 764c3c8
• Kernel Git Commit 815ddd2
• Kernel Git Commit 87d4954
• Kernel Git Commit d872683
• Kernel Git Commit faddeb8

Workarounds

• Unmount GFS2 filesystems on hosts that cannot be immediately patched and rely on alternative shared filesystems where feasible
• Limit local user accounts and untrusted workloads on systems exposing writable GFS2 mounts
• Reduce memory pressure on affected nodes to lower the probability of kswapd-driven reclamation triggering the race

# Verify the running kernel version and GFS2 module status
uname -r
lsmod | grep gfs2

# Identify mounted GFS2 filesystems
mount -t gfs2

# After patching, reboot into the fixed kernel
sudo reboot