Cloudanix VulnDB

CVE-2026-53041

None

CVSS

—

EPSS

0.1%

Published

Jun 24, 2026

CISA due date

—

Cloudanix analysis

Next patch cycle SSVC: Track

A flaw in a Linux shared-filesystem feature can let someone with local file access crash an affected server.

Exploitation
Local Privilege
Attacker needs
Local User
Complexity
Moderate
Impact
Denial Of Service
Component
OS kernel
Class
Denial of service
Remediation
Patch
Effort
Low
Patch risk
Low

What it actually does

This is a Linux kernel OCFS2 filesystem flaw in extended attribute listing. When an OCFS2 inode contains both inline and block-based extended attributes, and the caller supplies a listxattr() buffer that is exactly filled by the inline attribute names, the OCFS2 block-attribute pass can incorrectly continue accounting names beyond the remaining buffer size. The kernel may then attempt an invalid copy_to_user() operation and trigger a hardened usercopy BUG/Oops in mm/usercopy.c, resulting in a kernel crash or service disruption. The impact is denial of service; the provided details do not indicate privilege escalation, remote code execution, or data disclosure.

Why it matters to the business

Systems using OCFS2 can be crashed by a user or workload able to manipulate extended attributes on an OCFS2-mounted filesystem, causing downtime for applications that depend on the affected host or clustered filesystem. Because OCFS2 is commonly used in clustered or shared-storage deployments, a crash may have operational impact beyond a single process and can disrupt availability-sensitive services. The vulnerability is not currently listed in CISA KEV, is not known to be used in ransomware campaigns, has low EPSS, and has no reported exploit maturity, so remediation should be handled through normal kernel patching priorities unless OCFS2 is exposed to untrusted local users or multi-tenant workloads.

How an attack unfolds

An attacker needs the ability to access an OCFS2-mounted filesystem and create or modify extended attributes on files or directories. They prepare an inode with a combination of inline extended attributes and block-based extended attributes. They then call listxattr() with a destination buffer sized so that the inline attribute names consume the buffer exactly. Due to incorrect probe-mode detection in the OCFS2 xattr listing path, the block-based xattr pass continues processing with a non-NULL buffer and zero remaining space, returns a size larger than the provided buffer, and triggers the kernel hardened usercopy checks during copy_to_user(). On vulnerable kernels this can produce a kernel BUG/Oops and crash the system or destabilize the node.

How to fix it

Apply a Linux kernel update that includes the OCFS2 fix for listxattr() buffer-full handling. The corrected behavior detects probe mode by checking whether the destination buffer pointer is NULL rather than relying on the remaining size being zero, and returns -ERANGE when the supplied buffer is exhausted. No exact fixed package versions were provided, so use the vendor kernel advisory for the affected distribution or kernel branch and deploy the first version containing the OCFS2 xattr listxattr() fix. If immediate patching is not possible, reduce exposure by unmounting OCFS2 where it is not required, restricting access to OCFS2-mounted paths, preventing untrusted users or containers from setting extended attributes on OCFS2, and limiting local shell or workload access on systems that mount OCFS2.

How to confirm the fix worked

Confirm whether the running kernel includes the OCFS2 fix from the relevant vendor or upstream stable branch. Inventory systems for mounted OCFS2 filesystems using mount output, /proc/mounts, or filesystem management tooling. After patching, verify the active kernel version after reboot, not only the installed package version. For exposure validation, confirm whether OCFS2 is mounted and whether untrusted users, containers, or applications can create files and set extended attributes on those mounts. In a controlled non-production environment, a regression test can create an OCFS2 inode with both inline and block-based xattrs and call listxattr() with an exactly full buffer; a fixed kernel should return an error such as -ERANGE rather than producing a kernel BUG/Oops.

Typical attack path

  1. Gain local code execution or application-level file-write capability on a system with an OCFS2 filesystem mounted.
  2. Create or select a file or directory on OCFS2 where extended attributes can be set.
  3. Add enough inline extended attribute names to exactly fill a chosen listxattr() output buffer.
  4. Add additional block-based extended attributes to the same inode.
  5. Invoke listxattr() with the crafted buffer size.
  6. Trigger the OCFS2 xattr accounting bug, causing a hardened usercopy failure and kernel BUG/Oops.
  7. Cause denial of service through kernel crash, node reboot, or filesystem service disruption.

How to detect it

Review kernel logs, crash dumps, and system journals for signs of a kernel BUG/Oops in the hardened usercopy path involving listxattr() and OCFS2. Useful sources include dmesg, journalctl -k, /var/log/kern.log, /var/log/messages, /var/log/syslog, kdump/vmcore analysis, audit logs for setxattr/listxattr-heavy activity if syscall auditing is enabled, and EDR telemetry that records process syscalls or abnormal host reboots. Look for crashes with call traces containing usercopy_abort, __check_object_size, copy_to_user, listxattr, filename_listxattr, path_listxattrat, and OCFS2 xattr functions. Also investigate repeated creation or modification of extended attributes on OCFS2-mounted paths immediately before a crash. There are no public attacker-specific network indicators for this issue; detection is primarily host-based and crash-artifact based.

  • kernel BUG at mm/usercopy.c:102
  • usercopy_abort
  • Oops: invalid opcode
  • __check_heap_object
  • __check_object_size
  • copy_to_user
  • listxattr+
  • filename_listxattr
  • path_listxattrat
  • __x64_sys_listxattr
  • ocfs2_xattr_list_entry
  • ocfs2_listxattr
  • ocfs2
  • OCFS2
  • -ERANGE

What your security team should do

  • Identify all Linux systems that have OCFS2 mounted or the OCFS2 kernel module available and prioritize those with untrusted local users, container workloads, or shared application write access.
  • Patch affected kernels through the operating system or kernel vendor and reboot systems so the fixed kernel is active.
  • Where patching is delayed, restrict write and extended-attribute operations on OCFS2 mounts to trusted service accounts only.
  • Disable or unload OCFS2 on systems where it is not required, and remove unnecessary OCFS2 mounts from boot-time configuration.
  • Monitor kernel logs for usercopy_abort, OCFS2 xattr, listxattr, and kernel BUG/Oops patterns that may indicate attempted exploitation or accidental triggering.
  • Treat unexplained crashes on OCFS2 hosts as potentially security-relevant until kernel logs and filesystem activity are reviewed.
  • Because this issue is not KEV-listed, not associated with ransomware use, and has low EPSS, prioritize based on OCFS2 usage and local/multi-tenant exposure rather than internet exposure.

The record

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.

Affected packages

Ecosystem Package Introduced Fixed