CVE-2026-89492
UnknownSummary
A vulnerability was found in the Linux kernel's ocfs2 module due to missing validation of directory-index entry counts when reading metadata. The functions ocfs2_validate_dx_leaf() and ocfs2_validate_dx_root() do not bound the de_num_used and de_count fields against the block capacity, allowing a crafted on-disk image to set them to 0xffff and cause an out-of-bounds read past the 4KB metadata block. The flaw is reachable from any path lookup, stat() or open() on an indexed directory once the image is mounted.
Risk Assessment
The vulnerability allows an attacker with access to a crafted filesystem image to trigger a slab out-of-bounds read, potentially leading to kernel data disclosure or a system crash (denial of service). The risk is high in environments that mount untrusted ocfs2 images.
Recommendation
Update the Linux kernel to a version containing the fix that validates the de_count and de_num_used fields in ocfs2_validate_dx_leaf() and ocfs2_validate_dx_root(). Until patched, avoid mounting untrusted ocfs2 filesystem images.
Other vulnerabilities in Linux kernel (ocfs2)
See all- CVE-2026-89496Unknown
In the Linux kernel, the ocfs2 filesystem has a memory leak during copy-on-write operations triggered by copy_file_range() within the same filesystem. The issue was found by fuzzing and occurs because deallocations are not always run on copy-on-write completion, leading to unreferenced memory allocations.
- CVE-2026-89494Unknown
In the Linux kernel, the ocfs2 dlm_mig_lockres_handler trusted the num_locks and lockname_len fields from a DLM_MIG_LOCKRES message without validation. This led to an out-of-bounds read (BUG_ON panic) and a heap out-of-bounds write when copying the lock name into a fixed 32-byte object. Any node in the domain could trigger this.
- CVE-2026-89493Unknown
The Linux kernel ocfs2 module lacked validation of the rl_used and rl_count fields in the refcount block. A crafted or corrupted ocfs2 image with rl_used set to 0xffff causes an out-of-bounds read past the metadata block and a subsequent out-of-bounds memmove during a reflink (FICLONE) operation. Exploitation requires local access (CAP_SYS_ADMIN mounting a crafted image or raw write to the backing block device).
- CVE-2026-89490Unknown
In the Linux kernel, the ocfs2 function ocfs2_dir_foreach_blk_el() on 32-bit kernels incorrectly computed the directory position mask, clearing the high 32 bits of the position. When readdir() crossed the 4 GiB boundary, the position was reset, causing infinite re-enumeration of already-returned directory entries.
Original NVD description (English source)
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).