Description
In the Linux kernel, the following vulnerability has been resolved:

ocfs2: fix listxattr handling when the buffer is full

[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.
Published: 2026-06-24
Score: n/a
EPSS: n/a
KEV: No
Impact: n/a
Action: n/a
AI Analysis

Impact

The vulnerability arises in the Linux kernel’s ocfs2 filesystem when listxattr() processes inline and block‑based extended attributes. If the inline names exactly fill the user‑specified buffer, the subsequent block‑xattr pass incorrectly reports a larger size, causing the kernel to copy beyond the allocated space and trigger a bug. The outcome is a kernel panic, effectively locking the system and providing an attacker with a denial‑of‑service capability. The flaw is a classic buffer overrun that fails to validate copy boundaries, leading to system instability.

Affected Systems

All Linux kernel versions that implement the ocfs2 filesystem and precede the commit that introduced the fix (936b8834366e). The issue is not limited to a specific distribution but affects any kernel where that commit is absent. Users who are running a kernel that contains ocfs2 must determine whether their version includes the patch; otherwise, they are vulnerable.

Risk and Exploitability

With no EPSS score available, exploit probability cannot be quantified, but the impact of a kernel crash is extremely high, rendering the affected system unusable. The vulnerability is not listed in the CISA KEV catalog, suggesting no widely known exploitation at the time of this analysis. Nonetheless, the bug can be triggered by any local or potentially remote component that interacts with ocfs2 metadata, making it a high‑risk flaw. The lack of mitigation options other than patching, combined with the critical nature of a kernel panic, mandates rapid remediation.

Generated by OpenCVE AI on June 24, 2026 at 19:29 UTC.

Remediation

No vendor fix or workaround currently provided.

OpenCVE Recommended Actions

  • Apply a Linux kernel update that includes commit 936b8834366e or later, thereby deploying the eviction of the buffer‑overflow check.
  • If updating the kernel is not immediately feasible, restrict access to the OCFS2 filesystem so that only trusted administrative users can perform operations that trigger listxattr, and consider disabling or migrating the filesystem if it is not essential.
  • Implement system monitoring for kernel panic events and configure a watchdog or fail‑over mechanism to restore service automatically should a crash occur.
  • Apply any vendor‑supplied backports or recommendated patches for your distribution’s kernel when they become available, and verify the inclusion of the commit by checking the kernel version or commit hash if documentation permits.

Generated by OpenCVE AI on June 24, 2026 at 19:29 UTC.

Tracking

Sign in to view the affected projects.

Advisories

No advisories yet.

History

Wed, 24 Jun 2026 19:45:00 +0000

Type Values Removed Values Added
Weaknesses CWE-120
CWE-125

Wed, 24 Jun 2026 17:15:00 +0000

Type Values Removed Values Added
Description In the Linux kernel, the following vulnerability has been resolved: ocfs2: fix listxattr handling when the buffer is full [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.
Title ocfs2: fix listxattr handling when the buffer is full
First Time appeared Linux
Linux linux Kernel
CPEs cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
Vendors & Products Linux
Linux linux Kernel
References

Subscriptions

Linux Linux Kernel
cve-icon MITRE

Status: PUBLISHED

Assigner: Linux

Published:

Updated: 2026-06-24T16:29:47.501Z

Reserved: 2026-06-09T07:44:35.380Z

Link: CVE-2026-53041

cve-icon Vulnrichment

No data.

cve-icon NVD

No data.

cve-icon Redhat

No data.

cve-icon OpenCVE Enrichment

Updated: 2026-06-24T19:30:08Z

Weaknesses
  • CWE-120

    Buffer Copy without Checking Size of Input ('Classic Buffer Overflow')

  • CWE-125

    Out-of-bounds Read