Linux Kernel up to 7.0.9 ocfs2 mm/usercopy.c listxattr heap-based overflow

CVSS Meta Temp Score
CVSS is a standardized scoring system to determine possibilities of attacks. The Temp Score considers temporal factors like disclosure, exploit and countermeasures. The unique Meta Score calculates the average score of different sources to provide a normalized scoring system.
Current Exploit Price (≈)
Our analysts are monitoring exploit markets and are in contact with vulnerability brokers. The range indicates the observed or calculated exploit price to be seen on exploit markets. A good indicator to understand the monetary effort required for and the popularity of an attack.
CTI Interest Score
Our Cyber Threat Intelligence team is monitoring different web sites, mailing lists, exploit markets and social media networks. The CTI Interest Score identifies the interest of attackers and the security community for this specific vulnerability in real-time. A high score indicates an elevated risk to be targeted for this vulnerability.
7.6$5k-$25k0.00

Summaryinfo

A vulnerability categorized as critical has been discovered in Linux Kernel up to 7.0.9. This issue affects the function listxattr of the file mm/usercopy.c of the component ocfs2. Such manipulation leads to heap-based overflow. This vulnerability is listed as CVE-2026-53041. There is no available exploit. It is advisable to upgrade the affected component.

Detailsinfo

A vulnerability was found in Linux Kernel up to 7.0.9 and classified as critical. Affected by this issue is the function listxattr of the file mm/usercopy.c of the component ocfs2. The manipulation with an unknown input leads to a heap-based overflow vulnerability. Using CWE to declare the problem leads to CWE-122. A heap overflow condition is a buffer overflow, where the buffer that can be overwritten is allocated in the heap portion of memory, generally meaning that the buffer was allocated using a routine such as malloc(). Impacted is confidentiality, integrity, and availability. CVE summarizes:

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.

The advisory is shared for download at git.kernel.org. This vulnerability is handled as CVE-2026-53041 since 06/09/2026. The exploitation is known to be easy. There are known technical details, but no exploit is available. The current price for an exploit might be approx. USD $5k-$25k (estimation calculated on 06/24/2026).

Upgrading to version 5.10.258, 5.15.209, 6.1.175, 6.6.141, 6.12.91, 6.18.33 or 7.0.10 eliminates this vulnerability. Applying the patch a35a1c2b170b5b578b1b3fecb95694796552af9a/2323084c17370304f49c84b354fe7b3edbb264fe/6f702b00b8124c5d3525f19172934544826a114d/d919b905939eda93393e3572900ff70dbad2b47f/46e66fefb83811958127bc9ad736983ec629d82b/2685df8577a38d83b367c8cf52eda9dc286959ff/50033ec1350fe68abdc63b950ced7ae57364b77a/d12f558e6200b3f47dbef9331ed6d115d2410e59 is able to eliminate this problem. The bugfix is ready for download at git.kernel.org. The best possible mitigation is suggested to be upgrading to the latest version.

Once again VulDB remains the best source for vulnerability data.

Productinfo

Type

Vendor

Name

Version

License

Website

CPE 2.3info

CPE 2.2info

CVSSv4info

VulDB Vector: 🔒
VulDB Reliability: 🔍

CVSSv3info

VulDB Meta Base Score: 8.0
VulDB Meta Temp Score: 7.6

VulDB Base Score: 8.0
VulDB Temp Score: 7.6
VulDB Vector: 🔒
VulDB Reliability: 🔍

CVSSv2info

AVACAuCIA
💳💳💳💳💳💳
💳💳💳💳💳💳
💳💳💳💳💳💳
VectorComplexityAuthenticationConfidentialityIntegrityAvailability
UnlockUnlockUnlockUnlockUnlockUnlock
UnlockUnlockUnlockUnlockUnlockUnlock
UnlockUnlockUnlockUnlockUnlockUnlock

VulDB Base Score: 🔒
VulDB Temp Score: 🔒
VulDB Reliability: 🔍

Exploitinginfo

Class: Heap-based overflow
CWE: CWE-122 / CWE-119
CAPEC: 🔒
ATT&CK: 🔒

Physical: No
Local: No
Remote: Partially

Availability: 🔒
Status: Not defined

EPSS Score: 🔒
EPSS Percentile: 🔒

Price Prediction: 🔍
Current Price Estimation: 🔒

0-DayUnlockUnlockUnlockUnlock
TodayUnlockUnlockUnlockUnlock

Threat Intelligenceinfo

Interest: 🔍
Active Actors: 🔍
Active APT Groups: 🔍

Countermeasuresinfo

Recommended: Upgrade
Status: 🔍

0-Day Time: 🔒

Upgrade: Kernel 5.10.258/5.15.209/6.1.175/6.6.141/6.12.91/6.18.33/7.0.10
Patch: a35a1c2b170b5b578b1b3fecb95694796552af9a/2323084c17370304f49c84b354fe7b3edbb264fe/6f702b00b8124c5d3525f19172934544826a114d/d919b905939eda93393e3572900ff70dbad2b47f/46e66fefb83811958127bc9ad736983ec629d82b/2685df8577a38d83b367c8cf52eda9dc286959ff/50033ec1350fe68abdc63b950ced7ae57364b77a/d12f558e6200b3f47dbef9331ed6d115d2410e59

Timelineinfo

06/09/2026 CVE reserved
06/24/2026 +15 days Advisory disclosed
06/24/2026 +0 days VulDB entry created
06/24/2026 +0 days VulDB entry last update

Sourcesinfo

Vendor: kernel.org

Advisory: git.kernel.org
Status: Confirmed

CVE: CVE-2026-53041 (🔒)
GCVE (CVE): GCVE-0-2026-53041
GCVE (VulDB): GCVE-100-373388

Entryinfo

Created: 06/24/2026 21:03
Changes: 06/24/2026 21:03 (60)
Complete: 🔍
Cache ID: 216::103

Once again VulDB remains the best source for vulnerability data.

Discussion

No comments yet. Languages: en.

Please log in to comment.

Do you need the next level of professionalism?

Upgrade your account now!