Look up another CVE · open CVE-2026-89492 in the interactive tracker
CVE-2026-89492
ocfs2: validate directory-index entry counts when reading metadata
Published 2026-09-11 (37 days ago) by the Linux kernel CNA. Subsystem fs/ocfs2. Debian urgency: not yet assigned.
What to do, per Debian release
Debian's own status for CVE-2026-89492 in every release this site tracks, and what each one means in practice. Every status below is the one the Debian Security Team publishes for this CVE. source
| Release | Status | Version | What this means |
|---|---|---|---|
| Debian 12bookworm | vulnerable | 6.1.190-1 | No fix published anywhere yet, neither in Debian nor upstream for the series bookworm tracks. Watch the Debian tracker page for this CVE. Advisories for bookworm have historically landed a median of 23 days after publication. |
| Debian 13trixie | fixedDSA-6528-1 · 2026-09-29 · text | 6.12.111-1 | Update the kernel and reboot. DSA-6528-1 shipped the fix on 2026-09-29, in 6.12.111-1. A running kernel keeps the old code until the machine restarts. |
| Debian 14forky | fixed | 7.2.6-1 | Update the kernel and reboot. Fixed in 7.2.6-1. A running kernel keeps the old code until the machine restarts. |
| Debian unstablesid | fixed | 7.2.6-1 | Update the kernel and reboot. Fixed in 7.2.6-1. A running kernel keeps the old code until the machine restarts. |
| Debian 12bookworm · linux-6.12 | fixedDLA-4817-1 · 2026-10-04 · text | 6.12.111-1~deb12u1 | Update the kernel and reboot. DLA-4817-1 shipped the fix on 2026-10-04, in 6.12.111-1~deb12u1. A running kernel keeps the old code until the machine restarts. |
The vulnerability
What the bug is
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).
Where it lives
The fix touches these files. If the subsystem is one you do not use, the practical exposure is lower, though the package is still the vulnerable one.
fs/ocfs2/dir.c
- What this is
- ORACLE CLUSTER FILESYSTEM 2 (OCFS2)MAINTAINERS section matched on fs/ocfs2/ · ocfs2-devel@lists.linux.dev · Supported
- Kernel module
- ocfs2
Check it on the machine
grep -w CONFIG_OCFS2_FS /boot/config-$(uname -r)Reads the booted kernel's own configuration, on the machine and nowhere else. =y is built in, =m is a module, and an is not set line means the code is not there.
lsmod | grep -w ocfs2Prints a line if that module is loaded right now, and nothing if it is not. One that is not loaded can still be loaded later by anything that needs it.
Show whether Debian builds this, per release
Debian builds this, but not on every flavour. At least one release below builds the code on some of its kernel flavours and not on others, so the answer depends on the architecture and flavour installed.
- bookworm, trixie, forky, sid, bookworm · linux-6.12Mnot built on amd64/cloud-amd64, arm64/cloud-arm64
- M
- a module where it is built at all; some flavours do not build it
- Build switch
- CONFIG_OCFS2_FS
From the configuration Debian publishes for every kernel flavour it builds. It covers only the architectures Debian ships a linux-config package for, and nothing about a kernel you built yourself. Debian's own status above stays authoritative about the source package.MAINTAINERS kbuild Makefiles Debian linux-config packages
Signals
- Published
- 2026-09-11 (37 days ago)source
- CVSS
- 9.8 critical
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:Hsource recompute it - Attack vector
- network (AV:N)source
- EPSS
- 0.64%, higher than 49.4% of all CVEssource
- CISA KEV
- not listedthe KEV catalogue
- Debian urgency
- not yet assignedsource
- Subsystem
- fs/ocfs2
Upstream fixes
The versions the CNA records as introducing and fixing this, and the commit for each. source
| Introduced | Fixed in | Commit |
|---|---|---|
| 2.6.30 | 6.12.111 | 5e661f55ca85 |
| 2.6.30 | 6.18.51 | fcfcba8fe17d |
| 2.6.30 | 7.2.4 | b8a5c0c32df2 |
| 2.6.30 | 7.3 | bc70726ddad5 |
Debian advisories
| Advisory | Date | Shipped to | Debian |
|---|---|---|---|
| DLA-4817-1 | 2026-10-04 | bookworm 6.12.111-1~deb12u1 | tracker |
| DSA-6528-1 | 2026-09-29 | trixie 6.12.111-1 | tracker |
Why the CNA scored it this way
Quoted from the kernel CNA's own scoring file, word for word. A highlighted metric carries the most severe value CVSS v3.1 defines for it, which is what pushes the score up. source
- AV:NAttack vector, network
- OCFS2 sets s_export_op to ocfs2_export_ops and is commonly NFS-exported on shared cluster LUNs; remote nfsd LOOKUP/GETATTR/CREATE reach ocfs2_lookup→ocfs2_find_entry_dx→ocfs2_dx_dir_search (and create→ocfs2_dx_entry_list_insert) over the network with no local syscall on the server.
- AC:LAttack complexity, low
- The attacker fully controls on-disk de_num_used and de_count in a dx_root or dx_leaf; inflating them above the fixed 4K-block capacity (e.g. 0xffff with de_num_used still below de_count) deterministically overflows the entry walk and insert with no race or attacker-uncontrollable layout.
- PR:NPrivileges required, none
- Triggering needs only NFS LOOKUP or CREATE on an exported directory, including guest or anonymous NFS, or any unprivileged accessor of a mounted volume holding the forged index; planting malformed directory-index metadata on shared cluster storage does not require init-namespace root on the victim.
- UI:NUser interaction, none
- Once the OCFS2 volume is mounted and NFS-exported as a normal cluster or NAS deployment, the attacker triggers the overflow by their own LOOKUP, stat, open, or CREATE; no additional victim action such as mounting an image or opening a file is required.
- S:UScope, unchanged
- The overflow corrupts kernel memory and OCFS2 metadata on the host that parses the forged directory index; it does not escape a VM, bypass an IOMMU, or otherwise cross into a separate security authority.
- C:HConfidentiality impact, high
- ocfs2_dx_dir_search walks de_num_used with no capacity check, so de_num_used of 0xffff reads far past the 4KB metadata block (up to about 1 MiB of adjacent kernel memory), an unbounded out-of-bounds read that enables high-impact disclosure.
- I:HIntegrity impact, high
- When de_count is inflated past block capacity and de_num_used is still less than de_count, create/mkdir calls ocfs2_dx_entry_list_insert and writes a dx_entry at de_entries[de_num_used] past the block; unlink memmove is similarly unbounded, yielding an attacker-triggered kernel out-of-bounds write.
- A:HAvailability impact, high
- The unbounded out-of-bounds read on lookup and out-of-bounds write on create against kernel metadata buffers cause a kernel oops or panic, fully denying availability of the OCFS2 node until reboot.