REDHAT-BUG-2507750: Buffer Overflow

Published Jul 27, 2026
·
Updated

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.

Affected Software

1 affected component
gfs2-utils

Event History

Jul 27, 2026
Data Sourced
via Red Hat·09:02 PM
DescriptionSeverityAffected Software

Frequently Asked Questions

1

Who is realistically exposed to these flaws?

Systems are exposed when gfs2-utils utilities process crafted GFS2 filesystem images while running as root. Administrators or automated workflows that inspect untrusted GFS2 images are the relevant attack surface.

2

What must an attacker do to trigger the vulnerabilities?

An attacker needs to supply a crafted GFS2 filesystem image containing malicious metadata values. Exploitation occurs when a vulnerable utility processes that image with root privileges.

3

What is the potential impact of successful exploitation?

The reported issues include stack exhaustion crashes and stack buffer overflows. The report states that the unbounded stack allocation could lead to a crash or potential code execution.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203