CVE-2026-72164 in Linux
Summary
by MITRE • 08/15/2026
In the Linux kernel, the following vulnerability has been resolved:
ocfs2: avoid moving extents to occupied clusters
For non-auto OCFS2_IOC_MOVE_EXT operations, userspace supplies a physical me_goal. ocfs2_move_extent() initializes new_phys_cpos from that goal and expects ocfs2_probe_alloc_group() to replace it with a free run in the target block group.
The probe currently leaves *phys_cpos unchanged if the scan reaches the end of the group without finding a free run. An occupied goal at the last bit can therefore survive the probe and be passed to __ocfs2_move_extent(), which copies file data into a cluster still owned by another inode before the bitmap is updated.
When the probe does find a free run, it also subtracts move_len from the ending bit. The start of an N-bit run ending at i is i - N + 1, so the current calculation can report the bit immediately before the free run.
Clear *phys_cpos before scanning and use the correct free-run start. Callers already treat a zero result as -ENOSPC, so failed probes no longer continue with an occupied caller-controlled goal.
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 in question affects the OCFS2 (Oracle Cluster File System 2) implementation within the Linux kernel, specifically during non-auto extent movement operations. This issue arises from improper handling of physical cluster allocation when userspace provides a physical goal through the OCFS2_IOC_MOVE_EXT ioctl operation. The flaw stems from the ocfs2_move_extent() function's initialization of new_phys_cpos with a user-supplied goal value without proper validation of cluster availability within the target block group.
The technical root cause lies in the ocfs2_probe_alloc_group() function which is responsible for finding available clusters within a block group. When this probe function scans through a block group and fails to find a free run of clusters, it incorrectly leaves the *phys_cpos value unchanged rather than clearing it or setting it to indicate failure. This behavior allows an occupied cluster goal that happens to be located at the end of a block group to persist and be passed to subsequent operations. The problem is further compounded by incorrect calculation of free-run start positions when a suitable free run is actually found, as the function subtracts move_len from the ending bit inappropriately.
When an occupied cluster is passed to __ocfs2_move_extent() function, it attempts to copy file data into clusters that are still marked as owned by other inodes before updating the bitmap to reflect the new ownership. This creates a race condition and potential data corruption scenario where multiple inodes may attempt to write to the same physical cluster simultaneously, leading to data integrity issues and possible system instability. The vulnerability represents a classic case of improper input validation combined with insufficient state management in cluster allocation logic.
The operational impact of this vulnerability extends beyond simple data corruption to potentially compromise the entire file system's consistency and reliability. Attackers could exploit this weakness by carefully crafting physical goal values that would survive the probe phase, leading to malicious data overwrites or system crashes. The issue affects systems running OCFS2 file systems where userspace applications perform extent movement operations, particularly in clustered environments where multiple nodes access shared storage. This vulnerability directly relates to CWE-129 and CWE-787, representing improper input validation and out-of-bounds write conditions respectively.
Mitigation strategies should focus on ensuring proper initialization of physical cluster positions before allocation scans begin and implementing correct free-run start calculation logic. The fix requires clearing *phys_cpos before scanning begins and using accurate calculations for determining the starting position of free runs. This approach aligns with ATT&CK technique T1566 which involves credential access through exploitation of file system vulnerabilities, and T1490 which covers data destruction via file system corruption. System administrators should ensure immediate patch deployment and consider monitoring for unusual extent movement patterns that might indicate exploitation attempts. The solution addresses fundamental issues in resource allocation management and bitmap consistency handling within the OCFS2 subsystem, reinforcing proper state transitions between allocation phases to prevent concurrent access violations.