Description

In the Linux kernel, the following vulnerability has been resolved: ocfs2: validate directory-index entry counts when reading metadata ocfs2_validate_dx_leaf() and ocfs2_validate_dx_root() check the ECC and signature of an indexed-directory block before it reaches higher-level callers, but neither validator bounds the ocfs2_dx_entry_list counts against the capacity of the block that holds them. ocfs2_dx_dir_search() then walks for (i = 0; i < le16_to_cpu(entry_list->de_num_used); i++) dx_entry = &entry_list->de_entries[i]; over de_num_used entries with no bounds check. entry_list is either dx_leaf->dl_list (from ocfs2_read_dx_leaf) or, for an inline root, dx_root->dr_entries. A crafted on-disk image can set de_num_used (and de_count, which is the __counted_by_le() bound of de_entries) to 0xffff and make the walk read far past the end of the 4KB metadata block, giving a slab out-of-bounds read reachable from any path lookup, stat() or open() on an indexed directory once the image is mounted. Commit 775c17386a6f ("ocfs2: validate dx_root extent list fields during block read") already bounds dr_list for the non-inline dx_root, but left the inline dr_entries path and the dx_leaf dl_list unchecked. Add the same read-time validation for both entry lists: de_count must equal the capacity of the block (ocfs2_dx_entries_per_leaf()/per_root()) and de_num_used must not exceed de_count, rejecting corrupted metadata with -EFSCORRUPTED before ocfs2_dx_dir_search() can walk an out-of-range entry array. de_count is always written as exactly the block capacity when a leaf or inline root is formatted, so the equality check does not reject any valid image. Found by 0sec automated security-research tooling (https://0sec.ai).

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "9.8",
  "pubDate": "2026-09-11T20:19:31.090Z",
  "pubdate": "2026-09-11T20:19:31.090Z",
  "executiveSummary": "This vulnerability is an out-of-bounds (OOB) memory read within the Linux kernel OCFS2 (Oracle Cluster File System version 2) implementation.\nThe flaw exists in the validation logic for indexed-directory metadata, specifically regarding the handling of ocfs2_dx_entry_list counts.\nBy manipulating on-disk metadata to provide malicious values for de_num_used and de_count, an attacker can force the kernel to perform out-of-bounds reads during directory search operations.\nSuccessful exploitation results in potential information disclosure from kernel memory and system instability, including kernel panics (denial of service).\nThe vulnerability is reachable through common filesystem operations such as open(), stat(), or path lookups once a malicious or corrupted filesystem image is mounted.\nThis issue represents a significant security concern for systems utilizing OCFS2, as it allows unprivileged local users or malicious external entities providing filesystem images to trigger memory corruption scenarios.",
  "technicalDetails": "The vulnerability originates from inadequate bounds checking within the OCFS2 directory indexing validation routines, specifically ocfs2_validate_dx_leaf() and ocfs2_validate_dx_root(). While these functions verify ECC and signatures, they fail to validate the ocfs2_dx_entry_list counts against the actual size of the containing 4KB metadata block.\nThe vulnerable component is the directory entry iteration logic inside ocfs2_dx_dir_search(). The loop iterates using 'i < le16_to_cpu(entry_list->de_num_used)' to access 'entry_list->de_entries[i]'.\nAn attacker can construct a malicious OCFS2 filesystem image where the 'de_num_used' and 'de_count' fields are set to 0xffff. Because 'de_count' functions as a '__counted_by_le()' bound for the 'de_entries' array, an attacker can manipulate these values to exceed the physical capacity of the metadata block.\nThe attack flow proceeds as follows: 1. A malicious filesystem image is mounted, or a legitimate filesystem is corrupted. 2. A user or process executes a system call that requires a directory lookup (e.g., stat(), open(), or simple path resolution) on the indexed directory. 3. The kernel invokes ocfs2_dx_dir_search(), which trusts the 'de_num_used' value extracted from the on-disk metadata. 4. The iteration loop proceeds past the 4KB boundary of the metadata block into adjacent slab memory.\nThis out-of-bounds read allows an attacker to leak sensitive data stored in kernel slab memory or induce a kernel panic due to invalid memory access. The vulnerability is highly accessible as it does not require complex remote network exploitation, provided the attacker can influence the filesystem content processed by the kernel."
}