CVE-2026-71220 is a stack out-of-bounds write in gfs2_edit, part of gfs2-utils on Red Hat Enterprise Linux. The record scores it high (CVSS 7.0) and Red Hat assesses it as Moderate impact. It needs an administrator to run the tool on a crafted GFS2 image. Do that only on trusted images until patched.
What's affected
Red Hat Enterprise Linux, through the gfs2-utils package. The record gives no versions. The Red Hat CVE page, which I fetched, gives a mitigation but I did not find a fixed package version there, so check Red Hat's page and your errata feed for the current status of your RHEL release.
The weakness is CWE-787. In gfs2_edit, the di_height field from on-disk inode metadata is used as an array index without a bounds check. A crafted filesystem image can cause a stack buffer overflow that may lead to code execution. Red Hat states the kernel GFS2 driver is not affected, because it validates di_height.
Severity differs by source. The record and NVD give 7.0 high, while Red Hat's own statement rates impact Moderate, noting that it needs local access, high complexity and a user running the tool. Both can be right.
How to check if you're exposed
See whether gfs2-utils is installed:
rpm -q gfs2-utils
If it is not installed, you are not exposed through this package. If it is, check Red Hat's CVE page for your release and compare the installed version with the fixed erratum once one is listed:
dnf updateinfo list cves --cve CVE-2026-71220
The question after that is who runs gfs2_edit and on what images. The tool is a low level debugging editor for GFS2, used by administrators on cluster storage. Check your runbooks and automation for any step that runs it on images from outside your control.
Red Hat's mitigation also mentions automatic fsck at boot. free in-browser dependency scan checks application dependencies and will not see this OS package.
What to do now
- Check whether gfs2-utils is installed with rpm -q gfs2-utils.
- Do not run gfs2_edit on untrusted or possibly compromised GFS2 images.
- If you must inspect untrusted images, do it in a container or virtual machine isolated from production.
- Per Red Hat's mitigation, consider setting fs_passno to 0 in /etc/fstab for GFS2 filesystems to disable automatic fsck at boot until patches are applied.
- Watch the Red Hat CVE page for the fixed package and apply it.
Why it matters
CWE-787 on the stack is the older, better understood form of memory corruption. Red Hat's statement says the attacker controls the array index and can overwrite the return address, and that compiler hardening in RHEL (stack protector, PIE, ASLR) gives partial but not full protection.
The interesting part is where the input comes from: the filesystem image itself. Disk images are data that people tend to trust. Any tool that parses on disk structures needs to treat the image as hostile if it comes from a customer, a backup of unknown origin, or a compromised host.
Quick check
Is the kernel GFS2 driver affected?
Red Hat states it is not, because the kernel driver validates di_height against sd_max_height. The flaw is in the userspace tool gfs2_edit.
Sources
Last reviewed: 18 October 2026.
