GHSA-PGCV-8W9Q-57F9
Vulnerability from github – Published: 2026-09-11 21:31 – Updated: 2026-10-30 15:33In 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).
{
"affected": [],
"aliases": [
"CVE-2026-89492"
],
"database_specific": {
"cwe_ids": [],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-09-11T20:19:31Z",
"severity": "CRITICAL"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nocfs2: validate directory-index entry counts when reading metadata\n\nocfs2_validate_dx_leaf() and ocfs2_validate_dx_root() check the ECC and\nsignature of an indexed-directory block before it reaches higher-level\ncallers, but neither validator bounds the ocfs2_dx_entry_list counts\nagainst the capacity of the block that holds them.\n\nocfs2_dx_dir_search() then walks\n\n\tfor (i = 0; i \u003c le16_to_cpu(entry_list-\u003ede_num_used); i++)\n\t\tdx_entry = \u0026entry_list-\u003ede_entries[i];\n\nover de_num_used entries with no bounds check. entry_list is either\ndx_leaf-\u003edl_list (from ocfs2_read_dx_leaf) or, for an inline root,\ndx_root-\u003edr_entries. A crafted on-disk image can set de_num_used (and\nde_count, which is the __counted_by_le() bound of de_entries) to 0xffff\nand make the walk read far past the end of the 4KB metadata block, giving\na slab out-of-bounds read reachable from any path lookup, stat() or open()\non an indexed directory once the image is mounted.\n\nCommit 775c17386a6f (\"ocfs2: validate dx_root extent list fields during\nblock read\") already bounds dr_list for the non-inline dx_root, but left\nthe inline dr_entries path and the dx_leaf dl_list unchecked. Add the\nsame read-time validation for both entry lists: de_count must equal the\ncapacity of the block (ocfs2_dx_entries_per_leaf()/per_root()) and\nde_num_used must not exceed de_count, rejecting corrupted metadata with\n-EFSCORRUPTED before ocfs2_dx_dir_search() can walk an out-of-range entry\narray.\n\nde_count is always written as exactly the block capacity when a leaf or\ninline root is formatted, so the equality check does not reject any valid\nimage.\n\nFound by 0sec automated security-research tooling (https://0sec.ai).",
"id": "GHSA-pgcv-8w9q-57f9",
"modified": "2026-10-30T15:33:19Z",
"published": "2026-09-11T21:31:28Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-89492"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3497aa757788de5d904f41814f1df0b292a8be09"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3f28574dd59672ac47f3110c9a8ead703ec021c0"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/47b8152ed7709f7ef30b398fb0bfe4b452dd0495"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/5e661f55ca8568471fce558effe81cca112f5cb2"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/aad3129b8e915d0ff492bb7517d825d8490cfdd9"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b8a5c0c32df2c5b685ceef76ac77e37c7e1dc3ed"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/bc70726ddad53c7e9a9a85915bf2415b0d4f42f9"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/fcfcba8fe17dbf2c8805690b8cc25e32d81249a4"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
Drag nodes to arrange them. Double-click a related vulnerability to open it, or a source to visit its link. The Physics button on the left tunes the layout and the simulation; the legend at the bottom left hides or shows nodes by kind and by sighting type.
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
Vulnerability timeline
Sightings and recorded dates, grouped by day · UTC
How durations are calculated
Following the VTEM framework (Black Hat USA 2015), time to patch starts when the vendor or a coordinator was informed, total time to patch at discovery, and disclosure to patch at public disclosure; vendor response time runs from the report to its acknowledgement. Time to exploit and time unpatched start at the earliest discovery or report, falling back to public disclosure. Unpatched time ends at the first recorded patch, or the calculation time when no patch is recorded. Exploitation to patch shows the interval between those two events; a published proof of concept is a public exploit, not exploitation.
Each result shows its source dates. A negative interval means the end event came first; when date-only inputs leave the order open, the result says so. Date-only inputs are approximate. The earliest evidence wins: KEV report dates and sightings are labelled as such. Records describing another vulnerability are listed but never calculated from, and a PoC alone does not establish exploitation. Missing patch evidence does not prove that no patch exists. Filters below change the event list only.
Loading timeline…
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
Related by attack behaviour
Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.