CVE-2026-71224: Gfs2-utils: gfs2-utils: stack overflow via alloca(i_height) in metadata walk
A flaw was found in gfs2-utils. The metadata walk code in metawalk.c uses alloca((height + 1) sizeof(metalist)) where height is the iheight field from the on-disk inode (uint16, max 65535, valid range 0-10). No bounds validation is performed before the alloca call. An attacker can craft a GFS2 filesystem image with a large iheight value to cause excessive stack allocation (~1MB for iheight=65535 with sizeof(osilistt)=16), leading to stack exhaustion and a denial of service (SIGSEGV). The metadata walk in metawalk.c involves recursive traversal, and each level could invoke this alloca, compounding the stack usage. The Linux kernel GFS2 driver validates iheight against sdmaxheight in gfs2dinodein() and stores it as u8, but the userspace gfs2-utils performs no equivalent validation.
Other sources
A stack overflow vulnerability was found in gfs2-utils. The metadata walk code in metawalk.c uses alloca() with an untrusted inode height value from on-disk metadata without bounds validation, causing stack exhaustion and a denial of service when processing crafted GFS2 filesystem images.
— NVD
Gfs2-utils: gfs2-utils: stack overflow via alloca(iheight) in metadata walk
— Microsoft
Affected Software
Event History
Frequently Asked Questions
Who is realistically exposed to this issue?
Systems that use gfs2-utils to process GFS2 filesystem images are exposed when those images may be attacker-controlled or otherwise untrusted. The issue is in the userspace utilities; the Linux kernel GFS2 driver performs height validation that gfs2-utils lacks.
What must an attacker provide to trigger the denial of service?
An attacker needs to craft a GFS2 filesystem image containing an on-disk inode with an excessively large i_height value and cause gfs2-utils to perform the affected metadata walk. Exploitation also requires user interaction according to the supplied vector.
How can an affected image be identified?
Inspect GFS2 on-disk inode metadata for i_height values outside the valid range of 0 through 10. The vulnerable metadata walk allocates stack memory before validating this field.
What can be done if patching is not immediately possible?
Avoid using gfs2-utils to inspect, repair, or otherwise process untrusted GFS2 filesystem images. Validate inode i_height values before running affected metadata-walk operations, rejecting values above 10.