REDHAT-BUG-2507750: Buffer Overflow
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
Event History
Frequently Asked Questions
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.
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.
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.