UBUNTU-CVE-2026-89492: High severity ubuntu/linux vulnerability
In the Linux kernel, the following vulnerability has been resolved: ocfs2: validate directory-index entry counts when reading metadata ocfs2validatedxleaf() and ocfs2validatedxroot() check the ECC and signature of an indexed-directory block before it reaches higher-level callers, but neither validator bounds the ocfs2dxentrylist counts against the capacity of the block that holds them. ocfs2dxdirsearch() then walks for (i = 0; i < le16tocpu(entrylist->denumused); i++) dxentry = &entrylist->deentries[i]; over denumused entries with no bounds check. entrylist is either dxleaf->dllist (from ocfs2readdxleaf) or, for an inline root, dxroot->drentries. A crafted on-disk image can set denumused (and decount, which is the countedbyle() bound of deentries) 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 dxroot extent list fields during block read") already bounds drlist for the non-inline dxroot, but left the inline drentries path and the dxleaf dllist unchecked. Add the same read-time validation for both entry lists: decount must equal the capacity of the block (ocfs2dxentriesperleaf()/perroot()) and denumused must not exceed decount, rejecting corrupted metadata with -EFSCORRUPTED before ocfs2dxdirsearch() can walk an out-of-range entry array. decount 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).
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
ubuntu/linux-hwe-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-42.42~24.04.1 - Upgrade
Upgrade
ubuntu/linux-riscv-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-42.42.1~24.04.1 - Upgrade
Upgrade
ubuntu/linuxto a version that resolves this vulnerability.Fixed in 7.0.0-42.42 - Upgrade
Upgrade
ubuntu/linux-awsto a version that resolves this vulnerability.Fixed in 7.0.0-1016.17 - Upgrade
Upgrade
ubuntu/linux-gcpto a version that resolves this vulnerability.Fixed in 7.0.0-1016.18 - Upgrade
Upgrade
ubuntu/linux-ibmto a version that resolves this vulnerability.Fixed in 7.0.0-1017.17 - Upgrade
Upgrade
ubuntu/linux-oem-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-1017.17 - Upgrade
Upgrade
ubuntu/linux-oracleto a version that resolves this vulnerability.Fixed in 7.0.0-1015.16 - Upgrade
Upgrade
ubuntu/linux-riscvto a version that resolves this vulnerability.Fixed in 7.0.0-42.42.1 - Compensating control
In ocfs2_dx_validate_dx_leaf() and ocfs2_validate_dx_root(), validate both directory-index entry lists before ocfs2_dx_dir_search(): require de_count to equal the block capacity returned by ocfs2_dx_entries_per_leaf() or ocfs2_dx_entries_per_root(), and require de_num_used <= de_count; reject corrupted metadata with -EFSCORRUPTED, covering dx_leaf->dl_list and inline dx_root->dr_entries.
Event History
Frequently Asked Questions
Which systems are exposed to this issue?
Systems running the listed Ubuntu Linux kernel packages are exposed when they mount an OCFS2 image containing a crafted indexed directory. Accessing that directory through path lookup, stat(), or open() can reach the vulnerable code.
What does an attacker need to exploit it?
An attacker needs to provide a crafted on-disk OCFS2 image that is mounted by the target system. The malicious directory-index metadata sets entry counts beyond the capacity of its 4 KB metadata block.
What is the likely impact of successful exploitation?
The malformed entry counts cause the kernel to read past the end of a slab-backed metadata block. The supplied severity vector indicates an availability impact, while confidentiality and integrity impacts are not indicated.
What can be done before an updated kernel is deployed?
Avoid mounting untrusted OCFS2 images. If a mounted OCFS2 image is suspected to be malicious, avoid path lookups, stat operations, and open operations involving indexed directories on that image until the kernel can be updated.