CVE-2026-89492
nicheSlab out-of-bounds read in Linux kernel ocfs2 indexed-directory validation
The Linux kernel's ocfs2 filesystem fails to bound-check the directory-index entry counts (de_count and de_num_used) in ocfs2_validate_dx_leaf() and ocfs2_validate_dx_root(), so a crafted on-disk image can declare up to 0xffff entries in a 4KB metadata block. Once such an image is mounted, any ordinary path lookup, stat(), or open() on an indexed directory drives ocfs2_dx_dir_search() to walk far past the end of the block, causing a slab out-of-bounds read that can disclose adjacent kernel memory or crash the system. An attacker needs the ability to supply and get mounted a malicious ocfs2 disk image, which limits practical targets despite the critical CVSS score of 9.8. Systems running affected kernels that mount ocfs2 filesystems — particularly from untrusted or externally supplied images — are impacted; the fix adds read-time validation rejecting corrupted metadata with -EFSCORRUPTED. No public proof of concept exists, the flaw is not in the CISA KEV catalog, and no exploitation in the wild has been reported.
What to do: Apply kernel updates from your distribution once the fix (validation that de_count equals block capacity and de_num_used does not exceed de_count) is backported, and reboot into the patched kernel. If ocfs2 is not needed, blocklist the module (e.g., modprobe.d blacklist) so untrusted images cannot be mounted, and verify no ocfs2 filesystems are currently mounted via /proc/filesystems or lsmod. Treat any ocfs2 image from an untrusted source as unmountable until patched, and watch logs for -EFSCORRUPTED errors indicating rejected corrupted metadata.
| Linux kernel (ocfs2 filesystem) | All kernel versions prior to the fix commit; the advisory does not specify exact fixed version numbers |
Order-of-magnitude estimate by the model from install counts, market share and public scan data it knows; verify before quoting.
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 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).
- Vector
- CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
In the news0 stories
No ingested article mentions this CVE yet.