CVE-2025-38710 in Linux
Summary
by MITRE • 09/04/2025
In the Linux kernel, the following vulnerability has been resolved:
gfs2: Validate i_depth for exhash directories
A fuzzer test introduced corruption that ends up with a depth of 0 in dir_e_read(), causing an undefined shift by 32 at:
index = hash >> (32 - dip->i_depth);
As calculated in an open-coded way in dir_make_exhash(), the minimum depth for an exhash directory is ilog2(sdp->sd_hash_ptrs) and 0 is invalid as sdp->sd_hash_ptrs is fixed as sdp->bsize / 16 at mount time.
So we can avoid the undefined behaviour by checking for depth values lower than the minimum in gfs2_dinode_in(). Values greater than the maximum are already being checked for there.
Also switch the calculation in dir_make_exhash() to use ilog2() to clarify how the depth is calculated.
Tested with the syzkaller repro.c and xfstests '-g quick'.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 02/10/2026
The vulnerability CVE-2025-38710 affects the Linux kernel's gfs2 file system implementation and represents a critical integer overflow condition that can lead to undefined behavior and potential system instability. This flaw manifests in the exhash directory handling mechanism where improper validation of directory depth parameters creates a scenario for bit shift operations with invalid values. The issue was discovered through fuzzer testing that introduced data corruption, specifically causing the directory index depth parameter to reach zero during the dir_e_read() function execution. When the code attempts to perform a right bit shift operation with a 32-bit shift value, it creates undefined behavior that can result in system crashes or exploitable conditions.
The technical root cause stems from a calculation error in the directory hash management system where the depth parameter validation is insufficient. The problematic code executes index = hash >> (32 - dip->i_depth) where dip->i_depth can become zero due to corrupted data, leading to a shift by 32 bits which is undefined behavior in standard integer arithmetic. The gfs2 file system calculates the minimum valid depth as ilog2(sdp->sd_hash_ptrs) where sdp->sd_hash_ptrs is fixed at mount time to bsize / 16, making zero an invalid depth value. This represents a classic case of inadequate input validation that falls under CWE-191 Integer Underflow/Overflow, specifically involving bit shift operations with invalid parameters. The vulnerability demonstrates poor error handling in the gfs2_dinode_in() function which already validates maximum depth values but fails to check for minimum valid depth thresholds.
The operational impact of this vulnerability extends beyond simple system crashes to potentially enable privilege escalation or denial of service conditions within systems utilizing gfs2 file systems. Attackers could exploit this through controlled data corruption that forces directory depth values to zero, creating a condition where bit shift operations become undefined and potentially exploitable. The vulnerability affects systems where gfs2 file systems are mounted and actively used for directory operations, particularly in clustered environments where gfs2 is commonly deployed. This aligns with ATT&CK technique T1068, which involves local privilege escalation through kernel vulnerabilities, and T1499, which covers network denial of service attacks that can be initiated through kernel-level memory corruption. The flaw represents a significant security risk in enterprise environments where gfs2 is used for shared storage solutions.
Mitigation strategies should focus on immediate kernel updates that implement proper depth validation in the gfs2_dinode_in() function and correct the calculation method in dir_make_exhash() to use the ilog2() function as suggested in the patch. System administrators should prioritize applying the kernel patches that address this specific validation issue, which prevents the zero depth condition from occurring in the first place. The fix involves adding bounds checking to ensure that directory depth values remain within valid ranges, specifically preventing values below the calculated minimum depth. Additionally, monitoring systems should be enhanced to detect unusual directory operations that might indicate attempted exploitation of this vulnerability, particularly around hash table operations and directory traversal activities. Organizations should also consider implementing runtime protections such as kernel address space layout randomization and stack canaries to further reduce the exploitability of similar kernel vulnerabilities. The fix demonstrates proper defensive programming practices that align with secure coding guidelines for kernel development and represents a standard remediation approach for integer validation issues in system-level software.