Look up another CVE · open CVE-2026-90321 in the interactive tracker
CVE-2026-90321
ocfs2: validate inline xattrs during inode block validation
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-90321 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
Patch series "ocfs2: validate xattr entry bounds", v7. This series validates OCFS2 xattr entry name/value bounds when xattr metadata is read and validated, before getxattr() or listxattr() can walk out-of-range entry arrays or offsets from corrupted metadata. This patch (of 2): ocfs2_validate_inode_block() verifies a dinode before OCFS2 users walk metadata from it, but inline xattr metadata is still checked only in operation-specific consumers. The existing ibody lookup helper validates inline header placement and entry count, but inode block validation does not reject entry name/value bounds. Add a flat xattr entry validator and call it from inode block validation for inline xattrs. Keep the operation paths on their existing header/count lookup checks; the full entry bounds check now runs when the inode block is validated at read time. Reject corrupted inline xattr metadata before ocfs2_xattr_ibody_get() or listxattr() can walk past the inline storage. Validation reproduced this kernel report: BUG: KASAN: use-after-free in ocfs2_xattr_find_entry+0x5a/0x170 Read of size 2 at addr ffff8881242a2000 by task python3/529 Call Trace: dump_stack_lvl+0x66/0xa0 print_report+0xce/0x630 kasan_report+0xe0/0x110 ocfs2_xattr_find_entry+0x5a/0x170 ocfs2_xattr_get_nolock+0x20a/0x820 ocfs2_xattr_get+0x10c/0x1e0 __vfs_getxattr+0xe2/0x130 vfs_getxattr+0x185/0x1b0
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/inode.c
fs/ocfs2/xattr.c
fs/ocfs2/xattr.h
- 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 | 3fd45b24879f |
| 2.6.28 | 7.3 | 8914a3330b72 |
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 malformed bytes are dinode inline-xattr xe_name_offset, xe_name_len and xe_value_size, read from the inode block by ocfs2_read_inode_block() into ocfs2_validate_inode_block() and later walked by ocfs2_xattr_ibody_get()/ocfs2_xattr_ibody_list(); no o2net, NFS, or SMB message carries those offsets.
- AC:LAttack complexity, low
- A crafted dinode with OCFS2_INLINE_XATTR_FL and attacker-chosen xe_name_offset/xe_value_size is sufficient; after mount, getxattr(2) reaches vfs_getxattr()→ocfs2_xattr_get()→ocfs2_xattr_find_entry() and hits the reported KASAN UAF with no race or other condition outside the attacker’s control.
- PR:NPrivileges required, none
- ocfs2_fs_type.fs_flags has no FS_USERNS_MOUNT, so the attacker cannot self-mount; ocfs2_xa_set() writes well-formed inline entries, so planting a bad xe_name_offset needs a crafted image. After the victim’s ocfs2_fill_super(), listxattr(2) calls ocfs2_listxattr() with no MAY_READ/DAC check.
- UI:RUser interaction, required
- The inline xattr payload is inert until a victim mounts the crafted OCFS2 image through ocfs2_fill_super(); getxattr(2) or listxattr(2) on that volume is the follow-on action that reaches ocfs2_xattr_find_entry() or ocfs2_xattr_list_entries().
- S:UScope, unchanged
- The OOB/UAF is in the dinode buffer_head parsed by ocfs2_validate_inode_block() on the same host that mounted the volume and does not cross a VM, IOMMU, or guest-to-host boundary.
- C:HConfidentiality impact, high
- ocfs2_xattr_list_entries() memcpy’s xe_name_len bytes from header+xe_name_offset into the listxattr buffer, and ocfs2_xattr_ibody_get() memcpy’s xe_value_size bytes from that same unvalidated offset into the getxattr buffer; the repro is a KASAN UAF read of size 2 in ocfs2_xattr_find_entry().
- I:HIntegrity impact, high
- The same unvalidated xe_name_offset/xe_value_size are a kernel UAF/OOB walk of the inline region; ocfs2_xa_block_wipe_namevalue() memmove’s from header+min(xe_name_offset) with namevalue_size_xe() taken from on-disk xe_value_size when setxattr reuses that entry, a heap write primitive.
- A:HAvailability impact, high
- The KASAN report is a use-after-free in ocfs2_xattr_find_entry() from getxattr; namevalue_size_xe() BUG_ON()s when a local inline entry has xe_value_size > OCFS2_XATTR_INLINE_SIZE, and walking an out-of-range name/value offset can oops the node.