CVE-2025-38710
Description
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'.
AI Insight
LLM-synthesized narrative grounded in this CVE's description and references.
Undefined behavior in GFS2 directory operations due to missing depth validation for exhash directories, fixed by checking minimum depth.
Vulnerability
Overview
CVE-2025-38710 is a medium-severity vulnerability in the Linux kernel's GFS2 (Global File System) file system driver, specifically affecting the handling of exhash directories. The issue arises from insufficient validation of the i_depth field in directory inodes. When an exhash directory has an invalid depth of 0, the function dir_e_read() computes an index using the expression hash >> (32 - i_depth), which results in an undefined shift by 32 bits, triggering undefined behavior [1][2].
Exploitation and
Root Cause
The root cause is that the minimum allowed depth for an exhash directory—calculated as ilog2(sdp->sd_hash_ptrs), where sdp->sd_hash_ptrs equals the block size divided by 16—was not enforced during inode loading. While the kernel already checked for depths exceeding a maximum value, depths below the minimum were allowed, leaving a window for corruption or malicious input. A fuzzer discovered this vulnerability by introducing corrupted on-disk data with a depth of 0 [1].
Impact
An attacker with the ability to mount a crafted GFS2 file system could trigger this undefined behavior, potentially leading to a system crash or other unpredictable outcomes. The vulnerability is rated with a CVSS v3 score of 5.5 (Medium) and requires local access or the ability to introduce malformed file system metadata to exploit [1][2].
Mitigation and
Status
The fix has been applied to the Linux kernel stable tree in commits identifying and validating that the depth of an exhash directory is at least the minimum calculated value during gfs2_dinode_in(). The patch also clarifies the depth calculation in dir_make_exhash() by using ilog2(). Users should update their kernel to a version that includes the fix to eliminate the potential for undefined behavior [1][2].
AI Insight generated on May 19, 2026. Synthesized from this CVE's description and the cited reference URLs; citations are validated against the source bundle.
Affected products
2Patches
453a0249d68a2b5f46951e6239680c58675b8557c024ca725Vulnerability mechanics
Generated on May 9, 2026. Inputs: CWE entries + fix-commit diffs from this CVE's patches. Citations validated against bundle.
References
5- git.kernel.org/stable/c/53a0249d68a210c16e961b83adfa82f94ee0a53dnvdPatch
- git.kernel.org/stable/c/557c024ca7250bb65ae60f16c02074106c2f197bnvdPatch
- git.kernel.org/stable/c/9680c58675b82348ab84d387e4fa727f7587e1a0nvdPatch
- git.kernel.org/stable/c/b5f46951e62377b6e406fadc18bc3c5bdf1632a7nvdPatch
- git.kernel.org/stable/c/cddea0c721106ea480371412d8de21705eb27376nvd
News mentions
0No linked articles in our index yet.