Look up another CVE · open CVE-2026-90320 in the interactive tracker
CVE-2026-90320
ocfs2: validate external xattr entries when reading metadata
Published 2026-09-17 (31 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-90320 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 | vulnerable | 6.12.113-1 | No fix published anywhere yet, neither in Debian nor upstream for the series trixie tracks. Watch the Debian tracker page for this CVE. Advisories for trixie have historically landed a median of 11 days after publication. |
| 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. |
The vulnerability
What the bug is
ocfs2_validate_xattr_block() checks the xattr block header before the block reaches higher-level xattr users, but it does not verify that a non-indexed block's xh_count and entry offsets fit inside the block. Indexed buckets likewise reach list/get consumers after ECC without an entry-bounds check. Use the flat xattr entry validator for non-indexed external xattr blocks, and use a bucket-specific validator for indexed buckets at metadata read time. The bucket validator keeps the entry array bounded by the first bucket block while checking name/value offsets against the bucket block they target. Reject corrupted external xattr metadata before listxattr() or getxattr() can walk out-of-range entry arrays or name/value offsets. Validation reproduced this kernel report: BUG: KASAN: use-after-free in ocfs2_xattr_list_entries+0xd7/0x190 Read of size 1 at addr ffff88810a654007 by task ocfs2_xattr_lis/630 Call Trace: dump_stack_lvl+0x66/0xa0 print_report+0xce/0x630 kasan_report+0xe0/0x110 ocfs2_xattr_list_entries+0xd7/0x190 ocfs2_listxattr+0x3f6/0x610 listxattr+0x90/0xe0 path_listxattrat+0xed/0x220 do_syscall_64+0x115/0x6a0 entry_SYSCALL_64_after_hwframe+0x77/0x7f
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/xattr.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, sidMnot 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-17 (31 days ago)source
- CVSS
- 7.8 high
CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:Hsource recompute it - Attack vector
- local (AV:L)source
- EPSS
- 0.17%, higher than 6.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.28 | 7.2.6 | 9f4129b6905b |
| 2.6.28 | 7.3 | 2cf82b46d5e4 |
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:LAttack vector, local
- The attacker-controlled bytes are on-disk ocfs2_xattr_header.xh_count and ocfs2_xattr_entry.xe_name_offset in an external xattr block or bucket, read by ocfs2_read_xattr_block()/ocfs2_read_xattr_bucket() when path_listxattrat() reaches ocfs2_listxattr()→ocfs2_xattr_block_list(); no network protocol carries those fields.
- AC:LAttack complexity, low
- The crafted image fully controls xh_count and xe_name_offset; once the volume is mounted, ocfs2_xattr_list_entries() walks header->xh_entries[i] and forms name from xe_name_offset with no race, matching the deterministic KASAN UAF in that function.
- PR:NPrivileges required, none
- ocfs2_xa_set() writes well-formed entry arrays, so planting a bad xh_count needs a crafted image; ocfs2_fs_type has no FS_USERNS_MOUNT, so the attacker cannot self-mount, and after the victim's ocfs2_fill_super() vfs_listxattr() calls ocfs2_listxattr() with no MAY_READ/DAC check.
- UI:RUser interaction, required
- The malformed external xattr header is inert until a victim or admin mounts the crafted OCFS2 image through ocfs2_fill_super(); listxattr/getxattr on that volume is the follow-on action that reaches ocfs2_xattr_list_entries() or ocfs2_xattr_block_get().
- S:UScope, unchanged
- The OOB/UAF is in kernel buffers for the ocfs2_xattr_block or xattr bucket on the same host that parsed the metadata and does not cross a VM, IOMMU, or guest-to-host boundary.
- C:HConfidentiality impact, high
- ocfs2_xattr_list_entries() indexes xh_entries with unbounded on-disk xh_count, then memcpy's xe_name_len bytes from header+xe_name_offset into the listxattr buffer (copy_to_user); the repro is a KASAN UAF read of size 1 there, disclosing adjacent kernel memory.
- I:HIntegrity impact, high
- The same unvalidated xh_count/xe_name_offset are a kernel UAF/OOB walk; ocfs2_xa_bucket_add_entry() memmove's count*sizeof(ocfs2_xattr_entry) on setxattr and ocfs2_xattr_block_get() memcpy's xe_value_size from the unvalidated name offset, giving write/control-flow primitives.
- A:HAvailability impact, high
- The KASAN report is a use-after-free in ocfs2_xattr_list_entries() from listxattr; the unbounded xh_count walk and ocfs2_xattr_bucket_get_name_value() indexing bu_bhs[name_offset>>blocksize_bits] past bu_blocks can oops or panic the node.