CVE-2026-43262

What it actually does

This is a local denial-of-service flaw in the Linux kernel GFS2 filesystem implementation. The vulnerable path is gfs2_fiemap(), where the kernel calls iomap_fiemap() while holding a GFS2 inode glock. If the user-supplied fiemap buffer is memory-mapped to the same inode, accessing that buffer can trigger a page fault that attempts to reacquire the same lock recursively. This can deadlock or stall kernel execution paths associated with the affected GFS2 inode, potentially causing severe availability impact on systems using GFS2.

Why it matters to the business

Systems that use GFS2 can be made unstable or unresponsive by a local user or process with the ability to trigger the affected fiemap operation. The main risk is disruption of clustered filesystem availability, workload interruption, and possible node recovery or reboot requirements. This is not known to be remotely exploitable, is not listed in CISA KEV, has low EPSS, and has no reported mature public exploit, so urgency is highest for multi-user Linux systems, shared compute platforms, and production clusters that mount GFS2.

How an attack unfolds

An attacker first obtains local execution on a Linux system that uses a vulnerable kernel and has access to a GFS2-mounted filesystem. The attacker prepares a scenario where the fiemap output buffer is memory-mapped to the same inode being queried. They then invoke the fiemap operation, commonly through FS_IOC_FIEMAP or a utility/library path that reaches the kernel fiemap implementation. While gfs2_fiemap() holds the inode glock, the kernel attempts to access the user buffer. If that access faults, the page-fault handling path can re-enter GFS2 lock acquisition for the same inode, causing recursive glock acquisition and a deadlock or severe stall. The practical result is availability degradation rather than data theft or privilege escalation.

How to fix it

Upgrade to a Linux kernel build that includes the upstream GFS2 fiemap page-fault fix. Because no exact fixed versions were provided, use the latest security-maintained kernel from the relevant Linux distribution or vendor and verify that the GFS2 patch for gfs2_fiemap()/iomap_fiemap() page-fault handling is included. Reboot into the patched kernel after installation. If immediate patching is not possible, reduce exposure by limiting local shell or workload execution on systems that mount GFS2, restricting access to GFS2 mount points, disabling or avoiding untrusted workloads on affected systems, and monitoring for kernel hung-task or GFS2 glock symptoms. Systems that do not use or mount GFS2 are not materially exposed to this specific flaw.

How to confirm the fix worked

Confirm the active kernel version is a vendor-supported build containing the GFS2 fiemap page-fault fix, not merely that an updated package is installed. Validate with uname -a, package manager kernel version checks, and distribution security advisories or kernel changelogs referencing the GFS2 fiemap page-fault fix. Confirm whether GFS2 is in use by checking mounted filesystems and loaded modules, for example mount, findmnt -t gfs2, /proc/mounts, and lsmod for gfs2. After remediation, run operational checks against GFS2 workloads and review kernel logs for absence of new hung-task, glock, or fiemap-related stalls. In test environments, reproduce the applicable regression test coverage such as xfstests generic/742 where appropriate.

Typical attack path

1. Gain local code execution or an interactive account on a Linux system using a vulnerable kernel.
2. Identify or access a mounted GFS2 filesystem.
3. Create or select a file on the GFS2 filesystem and map memory in a way that causes the fiemap output buffer to reference the same inode.
4. Trigger a fiemap request against that inode, such as via FS_IOC_FIEMAP or software that requests file extent mappings.
5. Cause the kernel to fault while copying or accessing the fiemap buffer while the inode glock is held.
6. Induce recursive GFS2 glock acquisition, leading to a deadlock, task hang, or broader availability impact.

How to detect it

Look for signs of prior or attempted exploitation in kernel and system logs, especially on systems using GFS2. Relevant sources include dmesg output, journald kernel logs, /var/log/kern.log, /var/log/messages, /var/log/syslog, cluster/fencing logs, and workload logs around unexplained storage stalls. Focus on timestamps where GFS2-backed workloads became unresponsive, kernel hung-task warnings appeared, or cluster nodes were fenced or rebooted. Search for repeated fiemap activity from local processes if syscall auditing or eBPF telemetry is available, especially FS_IOC_FIEMAP ioctl calls against GFS2 files followed by page faults, blocked tasks, or glock messages. There are no known public exploit-specific file names, process names, registry keys, or network indicators for this issue; detection should emphasize behavioral evidence of local triggering and resulting kernel/GFS2 stalls.

• gfs2
• FS_IOC_FIEMAP
• fiemap
• gfs2_fiemap
• iomap_fiemap
• blocked for more than 120 seconds
• INFO: task
• hung_task_timeout_secs
• glock
• GFS2: fsid=
• BUG: scheduling while atomic
• page fault
• kernel: INFO: task

What your security team should do

• Inventory Linux systems that mount GFS2 or load the gfs2 kernel module and prioritize those for patch validation.
• Patch affected systems to a vendor kernel containing the GFS2 fiemap page-fault fix and reboot into the updated kernel.
• Prioritize shared, multi-user, clustered, and production GFS2 deployments because local users or compromised workloads could trigger availability impact.
• If patching is delayed, restrict untrusted local execution and access to GFS2 mount points, and consider moving sensitive workloads away from affected nodes.
• Monitor kernel logs for hung tasks, GFS2 glock activity, fiemap-related failures, filesystem stalls, and node fencing/recovery events.
• Do not treat this as a remote code execution or data exfiltration issue; focus response on availability, local access control, and kernel patch management.