CVE-2026-43262: Linux Kernel Privilege Escalation Flaw

CVE-2026-43262 Overview

CVE-2026-43262 affects the Linux kernel's Global File System 2 (GFS2) implementation. The flaw resides in gfs2_fiemap(), which calls iomap_fiemap() while holding the inode glock. When the user-supplied fiemap buffer is memory-mapped to the same inode, accessing the buffer triggers a page fault that attempts to acquire the same glock recursively. The condition was originally surfaced by the xfstest generic/742 test case. The upstream fix disables page faults for iomap_fiemap() and faults in the buffer manually when required.

Critical Impact

Local users on systems with GFS2 filesystems can trigger recursive glock acquisition, leading to denial-of-service conditions on affected kernels.

Affected Products

• Linux kernel — GFS2 filesystem subsystem
• Stable kernel branches referenced by the upstream commits
• Distributions shipping vulnerable GFS2 builds prior to backport

Discovery Timeline

• 2026-05-06 - CVE-2026-43262 published to NVD
• 2026-05-06 - Last updated in NVD database

Technical Details for CVE-2026-43262

Vulnerability Analysis

The defect is a kernel-level locking flaw in the GFS2 fiemap implementation. gfs2_fiemap() acquires the inode glock and then invokes iomap_fiemap() to populate the caller-provided buffer with extent mapping information. If the caller passes a buffer that is mmap()-backed by the same GFS2 inode, the kernel's copy-out path generates a page fault while the glock is still held. The page fault handler then re-enters GFS2 and attempts to take the same glock, producing a recursive lock-acquisition condition. This is a classic file-system [CWE-667] locking-order violation triggered by user-controlled buffer placement.

Root Cause

The root cause is the absence of page-fault disablement around the iomap_fiemap() copy-out while the inode glock is held. The function assumed the destination buffer would not fault back into the same inode, an assumption that breaks when userspace maps the inode and supplies that mapping as the fiemap target.

Attack Vector

A local, unprivileged user with read access to a GFS2 file can issue an ioctl(FS_IOC_FIEMAP) request whose fm_extents buffer is mmap()-mapped to the same file. The resulting recursive glock attempt stalls the filesystem path on the affected inode and can degrade availability on the cluster node. The vulnerability requires local access and a mounted GFS2 filesystem; no network exposure is involved.

The upstream patch disables page faults around the iomap_fiemap() call and faults the user buffer in by hand when a short copy is detected, breaking the recursive acquisition. See the upstream commits referenced below for implementation specifics, including Linux Kernel Commit 9d15fee and Linux Kernel Commit cead3be.

Detection Methods for CVE-2026-43262

Indicators of Compromise

• Processes blocked in D state with stacks showing gfs2_glock_nq re-entry from a page-fault path during FS_IOC_FIEMAP handling.
• Kernel hung_task warnings referencing gfs2_fiemap or iomap_fiemap on hosts mounting GFS2.
• Sudden unresponsiveness of GFS2-backed mounts following user-issued fiemap ioctls.

Detection Strategies

• Inventory running kernel versions and compare against the fixed stable releases listed in the upstream commit references.
• Audit local processes invoking FS_IOC_FIEMAP against files on GFS2 mounts, particularly when the calling process also mmap()s those files.
• Correlate dmesg lock-up messages with auditd syscall records for ioctl operations on GFS2 inodes.

Monitoring Recommendations

• Enable kernel lockdep on test systems to surface recursive glock acquisitions before production exposure.
• Forward /var/log/messages and dmesg output to a centralized log platform and alert on gfs2 hung-task traces.
• Track filesystem latency per-mount on GFS2 nodes to detect stalls indicative of glock contention.

How to Mitigate CVE-2026-43262

Immediate Actions Required

• Apply the stable-kernel updates that incorporate the GFS2 fiemap page-fault fix on every cluster node mounting GFS2.
• Reboot affected hosts after package upgrade so that the patched kernel image is the running kernel.
• Restrict local shell access on GFS2 cluster members to trusted operational accounts until patching completes.

Patch Information

The fix is delivered through multiple stable-tree backports. Reference commits include Linux Kernel Commit 2e121c5, Linux Kernel Commit 5d2c4f1, Linux Kernel Commit 5d5d9ec, Linux Kernel Commit 9d15fee, Linux Kernel Commit cead3be, Linux Kernel Commit e411d74, and Linux Kernel Commit e428670. Consume the corresponding kernel package from your distribution vendor.

Workarounds

• Where patching is not yet possible, limit GFS2 mount access to trusted users and constrain local logins on cluster nodes.
• Block or audit application use of FS_IOC_FIEMAP against mmap()-backed buffers on GFS2 paths through SELinux or seccomp policy.
• Schedule maintenance windows promptly; no fully equivalent runtime workaround exists for the locking flaw itself.

# Verify running kernel and confirm post-patch version
uname -r
rpm -q kernel || dpkg -l | grep linux-image
# Inspect dmesg for prior recursive-glock indications
dmesg | grep -Ei 'gfs2|hung_task|glock'