CVE-2026-74349 in Linux
Summary
by MITRE • 08/15/2026
In the Linux kernel, the following vulnerability has been resolved:
ocfs2: reject FITRIM ranges shorter than a cluster
ocfs2_trim_mainbm() trims the global bitmap in cluster units, but its too-short range validation only checks sb->s_blocksize.
On filesystems with a cluster size larger than the block size, a FITRIM range that is at least one block but shorter than one cluster is accepted and shifted down to len == 0. The later start + len - 1 and len -= ... arithmetic then underflows and can drive trimming past the requested range.
Reject ranges shorter than s_clustersize instead. That preserves the existing -EINVAL behavior for requests that cannot discard even one allocation unit and keeps zero-cluster trims out of the group walk.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 08/15/2026
The vulnerability resides in the ocfs2 filesystem implementation within the Linux kernel, specifically affecting the FITRIM functionality used for trimming unused space from storage devices. This issue demonstrates a critical flaw in input validation that can lead to unauthorized data manipulation and potential security risks. The problem manifests when the ocfs2_trim_mainbm() function processes trimming requests, where the validation logic fails to properly account for cluster size requirements relative to block size parameters.
The technical root cause stems from insufficient range validation within the FITRIM implementation. While the function correctly checks against sb->s_blocksize for minimum range requirements, it neglects to verify that ranges meet the cluster size threshold required by the filesystem. This oversight becomes particularly problematic on filesystems where cluster size exceeds block size, creating a scenario where a range can be accepted as valid despite being smaller than the minimum allocation unit. The validation failure allows ranges that are at least one block in length but shorter than a complete cluster to proceed through the processing pipeline.
When such invalid ranges are processed, the arithmetic operations within the trimming function cause integer underflow conditions that result in unintended behavior. Specifically, the start + len - 1 calculation combined with subsequent len -= ... operations can produce negative values that drive the trimming process beyond the originally requested boundaries. This misbehavior creates potential for data corruption or unauthorized access to filesystem structures outside of the intended trim scope, representing a significant security concern that aligns with CWE-191 Integer Underflow (Wrap or Wraparound) and CWE-704 Incorrect Type Conversion or Cast.
The operational impact of this vulnerability extends beyond simple data integrity concerns to potentially enable attackers to manipulate filesystem metadata in unexpected ways. The underflow conditions can cause the trimming process to operate on memory regions or data structures that should remain untouched, possibly leading to system instability or information disclosure. This issue particularly affects systems utilizing ocfs2 filesystems with non-uniform cluster and block size configurations, making it relevant to enterprise storage environments where such configurations are common. The vulnerability can be exploited through crafted FITRIM requests that leverage the size discrepancy between blocks and clusters to bypass normal validation checks.
The fix implemented addresses this vulnerability by modifying the range validation logic to properly check against s_clustersize rather than relying solely on sb->s_blocksize. This change ensures that trimming operations reject requests that cannot discard even a single allocation unit, maintaining consistent error handling behavior while preventing invalid ranges from entering the group walk processing phase. The solution aligns with ATT&CK technique T1490 Inhibit System Recovery by addressing potential data manipulation capabilities that could disrupt normal filesystem operations. Organizations deploying ocfs2 filesystems should apply this patch immediately to prevent exploitation of the integer underflow conditions that could enable unauthorized access to storage resources or compromise system stability through improper trimming operations.