Look up another CVE · open CVE-2026-53041 in the interactive tracker
CVE-2026-53041
ocfs2: fix listxattr handling when the buffer is full
Published 2026-06-24 (4 months 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-53041 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 | fixedDLA-4665-1 · 2026-07-03 · text | 6.1.176-1 | Update the kernel and reboot. DLA-4665-1 shipped the fix on 2026-07-03, in 6.1.176-1. A running kernel keeps the old code until the machine restarts. |
| Debian 13trixie | fixed | 6.12.94-1 | Update the kernel and reboot. Fixed in 6.12.94-1. A running kernel keeps the old code until the machine restarts. |
| Debian 14forky | fixed | 7.0.10-1 | Update the kernel and reboot. Fixed in 7.0.10-1. A running kernel keeps the old code until the machine restarts. |
| Debian unstablesid | fixed | 7.0.10-1 | Update the kernel and reboot. Fixed in 7.0.10-1. A running kernel keeps the old code until the machine restarts. |
The vulnerability
What the bug is
[BUG] If an OCFS2 inode has both inline and block-based xattrs, listxattr() can return a size larger than the caller's buffer when the inline names consume that buffer exactly. kernel BUG at mm/usercopy.c:102! Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI RIP: 0010:usercopy_abort+0xb7/0xd0 mm/usercopy.c:102 Call Trace: __check_heap_object+0xe3/0x120 mm/slub.c:8243 check_heap_object mm/usercopy.c:196 [inline] __check_object_size mm/usercopy.c:250 [inline] __check_object_size+0x5c5/0x780 mm/usercopy.c:215 check_object_size include/linux/ucopysize.h:22 [inline] check_copy_size include/linux/ucopysize.h:59 [inline] copy_to_user include/linux/uaccess.h:219 [inline] listxattr+0xb0/0x170 fs/xattr.c:926 filename_listxattr fs/xattr.c:958 [inline] path_listxattrat+0x137/0x320 fs/xattr.c:988 __do_sys_listxattr fs/xattr.c:1001 [inline] __se_sys_listxattr fs/xattr.c:998 [inline] __x64_sys_listxattr+0x7f/0xd0 fs/xattr.c:998 ... [CAUSE] Commit 936b8834366e ("ocfs2: Refactor xattr list and remove ocfs2_xattr_handler().") replaced the old per-handler list accounting with ocfs2_xattr_list_entry(), but it kept using size == 0 to detect probe mode. That assumption stops being true once ocfs2_listxattr() finishes the inline-xattr pass. If the inline names fill the caller buffer exactly, the block-xattr pass runs with a non-NULL buffer and a remaining size of zero. ocfs2_xattr_list_entry() then skips the bounds check, keeps counting block names, and returns a positive size larger than the supplied buffer. [FIX] Detect probe mode by testing whether the destination buffer pointer is NULL instead of whether the remaining size is zero. That restores the pre-refactor behavior and matches the OCFS2 getxattr helpers. Once the remaining buffer reaches zero while more names are left, the block-xattr pass now returns -ERANGE instead of reporting a size larger than the allocated list buffer.
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-06-24 (4 months ago)source
- CVSS
- 7.1 high
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:Hsource recompute it - Attack vector
- local (AV:L)source
- EPSS
- 0.13%, higher than 2.0% 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 | 5.10.258 | a35a1c2b170b |
| 2.6.28 | 5.15.209 | 2323084c1737 |
| 2.6.28 | 6.1.175 | 6f702b00b812 |
| 2.6.28 | 6.6.141 | d919b905939e |
| 2.6.28 | 6.12.91 | 46e66fefb838 |
| 2.6.28 | 6.18.33 | 2685df8577a3 |
| 2.6.28 | 7.0.10 | 50033ec1350f |
| 2.6.28 | 7.1 | d12f558e6200 |
Debian advisories
| Advisory | Date | Shipped to | Debian |
|---|---|---|---|
| DLA-4671-1 | 2026-07-05 | bullseye 6.1.176-1~deb11u1 | tracker |
| DLA-4665-1 | 2026-07-03 | bookworm 6.1.176-1 | tracker |
| DLA-4664-1 | 2026-07-03 | bullseye 5.10.259-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:LAttack vector, local
- The vulnerable OCFS2 code is reached through local `listxattr`/`llistxattr`/`flistxattr`/`listxattrat` syscalls where the caller controls the too-small buffer size. Network wrappers such as nfsd and ksmbd probe and allocate the full xattr-list size, so they do not expose the short-buffer trigger.
- AC:LAttack complexity, low
- The attacker can deterministically create the needed inline-plus-block xattr layout on a writable OCFS2 file using `user.*` xattrs, then pass a buffer size that exactly fits the inline names. No race or external timing condition is required.
- PR:LPrivileges required, low
- A basic local unprivileged user with access to a writable OCFS2 file or directory can create `user.*` xattrs and invoke `listxattr`. Creating/mounting the filesystem may require administrator setup, but exploitation on an affected deployed system does not require real root.
- UI:NUser interaction, none
- Once the attacker has local access to the OCFS2 path, exploitation is performed directly with syscalls. No separate victim action is needed.
- S:UScope, unchanged
- The issue affects kernel filesystem handling within the same host security authority. It is not a VM escape, IOMMU bypass, or other cross-scope boundary violation.
- C:HConfidentiality impact, high
- The bug returns a length larger than the allocated kernel xattr-list buffer, causing `copy_to_user` to attempt an out-of-bounds kernel heap read. With hardened usercopy this aborts, but without it or under weaker checking this can expose kernel memory, so confidentiality is high.
- I:NIntegrity impact, none
- The flaw is an oversized read/copy length and does not write beyond bounds or corrupt kernel objects. It does not provide a direct integrity modification primitive.
- A:HAvailability impact, high
- On hardened-usercopy kernels the overlong `copy_to_user` triggers `usercopy_abort()` and `BUG()`, producing a kernel oops/panic. The crash is repeatable by the local attacker.