A flaw was found in gfs2-utils. In the gfs2edit tool, the metapathtolblock() function in extended.c uses the diheight field from on-disk inode metadata as an array index into a fixed-size stack array factor[GFS2MAXMETAHEIGHT] (10 elements) without bounds validation. An attacker can craft a GFS2 filesystem image with diheight exceeding 10 (up to 65535) to write past the end of the array, corrupting adjacent stack memory including saved registers and the return address. The subsequent loop (factor[h] = factor[h+1] sbd.sdinptrs) amplifies the corruption by writing additional entries past the array boundary. This is a classic stack buffer overflow that may allow arbitrary code execution when gfs2edit processes the crafted image. The Linux kernel GFS2 driver validates diheight against sdmaxheight in gfs2dinodein(), but the userspace gfs2-utils performs no equivalent validation.

A flaw was found in gfs2-utils. The eanumptrs field from on-disk extended attribute metadata is used as a loop count in savemeta.c and metawalk.c without bounds validation. The eanumptrs field is a u8 (max 255). Each iteration reads a pointer (8 bytes) plus name data. With eanumptrs=255 and a 512-byte block buffer, the loop reads up to 1384 bytes past the buffer boundary, causing a heap out-of-bounds read. This may disclose sensitive heap memory contents through tool output or error messages, and the significant over-read (2.7x the allocation) has a non-trivial probability of crossing a page boundary into unmapped memory, causing a crash.

A flaw was found in gfs2-utils. In the gfs2edit tool, the metapathtolblock() function in extended.c uses the diheight field from on-disk inode metadata as an array index into a fixed-size stack array factor[GFS2MAXMETAHEIGHT] (10 elements) without bounds validation. An attacker can craft a GFS2 filesystem image with diheight exceeding 10 (up to 65535) to write past the end of the array, corrupting adjacent stack memory including saved registers and the return address. The subsequent loop (factor[h] = factor[h+1] sbd.sdinptrs) amplifies the corruption by writing additional entries past the array boundary. This is a classic stack buffer overflow that may allow arbitrary code execution when gfs2edit processes the crafted image. The Linux kernel GFS2 driver validates diheight against sdmaxheight in gfs2dinodein(), but the userspace gfs2-utils performs no equivalent validation.

A flaw was found in gfs2-utils. The eanumptrs field from on-disk extended attribute metadata is used as a loop count in savemeta.c and metawalk.c without bounds validation. The eanumptrs field is a u8 (max 255). Each iteration reads a pointer (8 bytes) plus name data. With eanumptrs=255 and a 512-byte block buffer, the loop reads up to 1384 bytes past the buffer boundary, causing a heap out-of-bounds read. This may disclose sensitive heap memory contents through tool output or error messages, and the significant over-read (2.7x the allocation) has a non-trivial probability of crossing a page boundary into unmapped memory, causing a crash.

A flaw was found in gfs2-utils. In the savemeta function in savemeta.c, the height value from on-disk inode metadata controls a loop over a fixed-size stack array (10 elements) without bounds validation. An attacker can craft a GFS2 filesystem image with a height value exceeding 10 to write past the end of the array, corrupting adjacent stack memory. This is the same vulnerability class as the diheight OOB write in gfs2edit (extended.c) but in a different code path. The stack buffer overflow may allow arbitrary code execution when savemeta processes the crafted image. The Linux kernel GFS2 driver validates iheight against sdmaxheight in gfs2dinodein(), but the userspace gfs2-utils performs no equivalent validation.

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.

A flaw was found in gfs2-utils. In the savemeta function in savemeta.c, the height value from on-disk inode metadata controls a loop over a fixed-size stack array (10 elements) without bounds validation. An attacker can craft a GFS2 filesystem image with a height value exceeding 10 to write past the end of the array, corrupting adjacent stack memory. This is the same vulnerability class as the diheight OOB write in gfs2edit (extended.c) but in a different code path. The stack buffer overflow may allow arbitrary code execution when savemeta processes the crafted image. The Linux kernel GFS2 driver validates iheight against sdmaxheight in gfs2dinodein(), but the userspace gfs2-utils performs no equivalent validation.

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.

This is a vulnerability report sent to us through https://issues.redhat.com/browse/PSIRTSUPT-17960 and was created using the PoC auto-triage agents. It contains hints on the vulnerability extracted by the IA and the full report. ALWAYS review it before any action. Once working on this, don't forget to also update the JSM ticket.

Six memory corruption vulnerabilities were found in gfs2-utils (the GFS2 filesystem utilities). All vulnerabilities are triggered by crafted GFS2 filesystem images and affect utilities that run as root. All findings were verified against upstream commit 8d07499.

The findings are:

1. Stack overflow via alloca(1<<didepth) with unbounded depth value read from superblock/inode metadata. An attacker-controlled didepth value causes an excessively large stack allocation, leading to stack exhaustion and crash or potential code execution. (CVSS 7.8, CWE-770)

2. Stack out-of-bounds write via unchecked diheight field in gfs2edit. The diheight value from inode metadata is used as an array index without bounds checking, enabling a stack buffer overflow. (CVSS 7.8, CWE-787)

3. Stack out-of-bounds write via unchecked height field in savemeta. Similar to finding 2, the height field is used without validation, causing a stack out-of-bounds write. (CVSS 7.8, CWE-787)

4. Heap out-of-bounds read via unchecked eanumptrs field. The eanumptrs value from extended attribute metadata is consumed without validation, causing a heap buffer over-read that may leak sensitive memory contents. (CVSS 5.5, CWE-125)

5. Integer overflow in resource group (rgrp) allocation size computation. An arithmetic overflow in the allocation size calculation leads to an undersized buffer allocation followed by out-of-bounds access. (CVSS 5.5, CWE-190)

6. Stack overflow via alloca(iheight) with unbounded inode height value. Similar to finding 1, an unbounded height value causes excessive stack allocation. (CVSS 5.5, CWE-770)

All vulnerable code paths reside in core filesystem metadata parsing logic within libgfs2 and utility-specific code that is unconditionally compiled into all shipped binaries. There are no build-time flags or conditional compilation options that can exclude the affected code. The most realistic attack scenario involves a crafted GFS2 image on removable or network-attached storage being processed by fsck.gfs2 (either automatically at boot or manually by an administrator) in a high-availability clustered environment.

RHEL compiler hardening (stack protector, FORTIFYSOURCE, PIE, full RELRO) provides partial mitigation for the CWE-787 stack out-of-bounds write vulnerabilities but is ineffective against alloca-based CWE-770 stack exhaustion.

No upstream fix or advisory has been published. The reporter has requested individual CVE assignment for each of the six distinct findings.

This is a vulnerability report sent to us through https://issues.redhat.com/browse/PSIRTSUPT-17960 and was created using the PoC auto-triage agents. It contains hints on the vulnerability extracted by the IA and the full report. ALWAYS review it before any action. Once working on this, don't forget to also update the JSM ticket.

Six memory corruption vulnerabilities were found in gfs2-utils (the GFS2 filesystem utilities). All vulnerabilities are triggered by crafted GFS2 filesystem images and affect utilities that run as root. All findings were verified against upstream commit 8d07499.

The findings are:

1. Stack overflow via alloca(1<<didepth) with unbounded depth value read from superblock/inode metadata. An attacker-controlled didepth value causes an excessively large stack allocation, leading to stack exhaustion and crash or potential code execution. (CVSS 7.8, CWE-770)

2. Stack out-of-bounds write via unchecked diheight field in gfs2edit. The diheight value from inode metadata is used as an array index without bounds checking, enabling a stack buffer overflow. (CVSS 7.8, CWE-787)

3. Stack out-of-bounds write via unchecked height field in savemeta. Similar to finding 2, the height field is used without validation, causing a stack out-of-bounds write. (CVSS 7.8, CWE-787)

4. Heap out-of-bounds read via unchecked eanumptrs field. The eanumptrs value from extended attribute metadata is consumed without validation, causing a heap buffer over-read that may leak sensitive memory contents. (CVSS 5.5, CWE-125)

5. Integer overflow in resource group (rgrp) allocation size computation. An arithmetic overflow in the allocation size calculation leads to an undersized buffer allocation followed by out-of-bounds access. (CVSS 5.5, CWE-190)

6. Stack overflow via alloca(iheight) with unbounded inode height value. Similar to finding 1, an unbounded height value causes excessive stack allocation. (CVSS 5.5, CWE-770)

All vulnerable code paths reside in core filesystem metadata parsing logic within libgfs2 and utility-specific code that is unconditionally compiled into all shipped binaries. There are no build-time flags or conditional compilation options that can exclude the affected code. The most realistic attack scenario involves a crafted GFS2 image on removable or network-attached storage being processed by fsck.gfs2 (either automatically at boot or manually by an administrator) in a high-availability clustered environment.

RHEL compiler hardening (stack protector, FORTIFYSOURCE, PIE, full RELRO) provides partial mitigation for the CWE-787 stack out-of-bounds write vulnerabilities but is ineffective against alloca-based CWE-770 stack exhaustion.

No upstream fix or advisory has been published. The reporter has requested individual CVE assignment for each of the six distinct findings.