CVE-2026-53041

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: __checkheapobject+0xe3/0x120 mm/slub.c:8243 checkheapobject mm/usercopy.c:196 [inline] __checkobjectsize mm/usercopy.c:250 [inline] __checkobjectsize+0x5c5/0x780 mm/usercopy.c:215 checkobjectsize include/linux/ucopysize.h:22 [inline] checkcopysize include/linux/ucopysize.h:59 [inline] copytouser include/linux/uaccess.h:219 [inline] listxattr+0xb0/0x170 fs/xattr.c:926 filenamelistxattr fs/xattr.c:958 [inline] pathlistxattrat+0x137/0x320 fs/xattr.c:988 __dosyslistxattr fs/xattr.c:1001 [inline] __sesyslistxattr fs/xattr.c:998 [inline] __x64syslistxattr+0x7f/0xd0 fs/xattr.c:998 ...

[CAUSE] Commit 936b8834366e ("ocfs2: Refactor xattr list and remove ocfs2xattrhandler().") replaced the old per-handler list accounting with ocfs2xattrlist_entry(), but it kept using size == 0 to detect probe mode.

That assumption stops being true once ocfs2listxattr() 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. ocfs2xattrlistentry() 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.