REDHAT-BUG-2511397: Medium severity gfs2-utils vulnerability
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.
Affected Software
Event History
Frequently Asked Questions
Who is realistically exposed to this issue?
Systems or workflows that run gfs2-utils metadata-walk functionality on untrusted or attacker-supplied GFS2 filesystem images are exposed. The affected parsing occurs in userspace gfs2-utils rather than the Linux kernel GFS2 driver.
What does an attacker need to exploit it?
An attacker needs to provide a crafted GFS2 filesystem image whose on-disk inode has an abnormally large i_height value. Processing that image through the vulnerable metadata walk can exhaust stack space and terminate the utility with SIGSEGV.
Is the kernel GFS2 driver affected in the same way?
The provided data indicates that the Linux kernel GFS2 driver validates i_height against sd_max_height and stores it as an 8-bit value. The missing equivalent validation is in userspace gfs2-utils.
Why can the stack exhaustion be worse than a single large allocation?
The metadata walk performs recursive traversal, and each traversal level can make the allocation based on i_height. This can compound stack consumption beyond the approximately 1 MB allocation possible when i_height is 65535 and osi_list_t is 16 bytes.