gfs2-utils CVE-2026-71219

Exploitation requires three concurrent conditions: (1) the attacker must be able to deliver or make accessible a crafted GFS2 filesystem image containing a manipulated di_depth inode field - this requires some level of write access to storage or delivery of the image to the target host; (2) a user or automated job must explicitly invoke fsck.gfs2, gfs2_edit, or savemeta against the crafted image (UI:R), meaning routine passive operation is not sufficient; (3) the host must be running a vulnerable version of gfs2-utils on RHEL 7, 8, or 9. Exploitation is limited to denial of service of the processing tool - there is no code execution, no data exposure, and the impact does not propagate beyond the crashing process.

Real-world risk is constrained by several factors. The CVSS 3.1 vector (AV:L/AC:H/PR:N/UI:R) correctly captures that exploitation requires both local access (the crafted image must be available on or delivered to the target filesystem) and user interaction (an administrator or automated job must invoke fsck.gfs2, gfs2_edit, or savemeta against the image). The AC:H metric in the vendor-supplied vector is debatable: the description states there is no bounds validation, implying any sufficiently large di_depth value triggers the overflow without needing precise tuning, which argues for AC:L. There is no EPSS score provided and this CVE is not in CISA KEV, consistent with a narrow, tool-triggered DoS affecting a niche workload. The SSVC technical impact is partial (DoS of the processing utility only, no code execution, no confidentiality or integrity breach). GFS2 is deployed primarily in RHEL cluster environments; administrators who regularly run fsck.gfs2 on externally-sourced images face the highest realistic exposure. No conflicting signals between CVSS and description except the AC disagreement noted above.

An attacker crafts a GFS2 filesystem image with a deliberately oversized di_depth value in an inode and persuades a storage or cluster administrator to run fsck.gfs2 against it - for example, by placing the image on a shared SAN LUN or submitting it as a disk image for review. When the administrator executes the check, metawalk.c allocates an exponentially large buffer on the stack via alloca(), exhausting stack space and crashing the tool. No public exploit code has been identified at time of analysis.