Strix
26.1K

CVE-2025-40306

HIGHCVSS 7.8/10EPSS 0.19%

Last modified

CVE-2025-40306 is a high-severity vulnerability rated 7.8/10 on the CVSS scale. In the Linux kernel, the following vulnerability has been resolved: orangefs: fix xattr related buffer overflow... Willy Tarreau <w@1wt.eu> forwarded me a message from Disclosure <disclosure@aisle.com> with the following warning: > The helper `xattr_key()` uses the pointer variable in the loop condition > rather than dereferencing it. As `key` is incremented, it remains non-NULL > (until it runs into unmapped memory), so the loop does not terminate on > valid C strings and will walk memory indefinitely, consuming CPU or hanging > the thread. I easily reproduced this with setfattr and getfattr, causing a kernel oops, hung user processes and corrupted orangefs files. EPSS estimates a 0.19% chance of exploitation in the next 30 days.

Description

In the Linux kernel, the following vulnerability has been resolved: orangefs: fix xattr related buffer overflow... Willy Tarreau <w@1wt.eu> forwarded me a message from Disclosure <disclosure@aisle.com> with the following warning: > The helper `xattr_key()` uses the pointer variable in the loop condition > rather than dereferencing it. As `key` is incremented, it remains non-NULL > (until it runs into unmapped memory), so the loop does not terminate on > valid C strings and will walk memory indefinitely, consuming CPU or hanging > the thread. I easily reproduced this with setfattr and getfattr, causing a kernel oops, hung user processes and corrupted orangefs files. Disclosure sent along a diff (not a patch) with a suggested fix, which I based this patch on. After xattr_key started working right, xfstest generic/069 exposed an xattr related memory leak that lead to OOM. xattr_key returns a hashed key. When adding xattrs to the orangefs xattr cache, orangefs used hash_add, a kernel hashing macro. hash_add also hashes the key using hash_log which resulted in additions to the xattr cache going to the wrong hash bucket. generic/069 tortures a single file and orangefs does a getattr for the xattr "security.capability" every time. Orangefs negative caches on xattrs which includes a kmalloc. Since adds to the xattr cache were going to the wrong bucket, every getattr for "security.capability" resulted in another kmalloc, none of which were ever freed. I changed the two uses of hash_add to hlist_add_head instead and the memory leak ceased and generic/069 quit throwing furniture.

Metrics

CVSS 3.1
7.8/10

CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

EPSS Probability
0.19%

9.3th percentile

Probability of exploitation in the next 30 days. Learn more

Affected Software

Source: CNA advisory (CVE.org). NVD analysis pending.

VendorProductVersions
LinuxLinux>= f7ab093f74bf638ed98fd1115f3efa17e308bb7f, < c6564ff6b53c9a8dc786b6f1c51ae7688273f931; >= f7ab093f74bf638ed98fd1115f3efa17e308bb7f, < ef892d2bf4f3fa2c8de1677dd307e678bdd3d865; >= f7ab093f74bf638ed98fd1115f3efa17e308bb7f, < 15afebb9597449c444801d1ff0b8d8b311f950ab; >= f7ab093f74bf638ed98fd1115f3efa17e308bb7f, < bc812574de633cf9a9ad6974490e45f6a4bb5126; >= f7ab093f74bf638ed98fd1115f3efa17e308bb7f, < e09a096104fc65859422817fb2211f35855983fe; >= f7ab093f74bf638ed98fd1115f3efa17e308bb7f, < 9127d1e90c90e5960c8bc72a4ce2c209691a7021; >= f7ab093f74bf638ed98fd1115f3efa17e308bb7f, < c2ca015ac109fd743fdde27933d59dc5ad46658e; >= f7ab093f74bf638ed98fd1115f3efa17e308bb7f, < 025e880759c279ec64d0f754fe65bf45961da864
LinuxLinux4.6

References

Timeline

Published
Last Modified
Status
Deferred

Frequently Asked Questions

What is CVE-2025-40306?
In the Linux kernel, the following vulnerability has been resolved: orangefs: fix xattr related buffer overflow... Willy Tarreau <w@1wt.eu> forwarded me a message from Disclosure <disclosure@aisle.com> with the following warning: > The helper `xattr_key()` uses the pointer variable in the loop condition > rather than dereferencing it. As `key` is incremented, it remains non-NULL > (until it runs into unmapped memory), so the loop does not terminate on > valid C strings and will walk memory indefinitely, consuming CPU or hanging > the thread. I easily reproduced this with setfattr and getfattr, causing a kernel oops, hung user processes and corrupted orangefs files. Disclosure sent along a diff (not a patch) with a suggested fix, which I based this patch on. After xattr_key started working right, xfstest generic/069 exposed an xattr related memory leak that lead to OOM. xattr_key returns a hashed key. When adding xattrs to the orangefs xattr cache, orangefs used hash_add, a kernel hashing macro. hash_add also hashes the key using hash_log which resulted in additions to the xattr cache going to the wrong hash bucket. generic/069 tortures a single file and orangefs does a getattr for the xattr "security.capability" every time. Orangefs negative caches on xattrs which includes a kmalloc. Since adds to the xattr cache were going to the wrong bucket, every getattr for "security.capability" resulted in another kmalloc, none of which were ever freed. I changed the two uses of hash_add to hlist_add_head instead and the memory leak ceased and generic/069 quit throwing furniture.
How severe is CVE-2025-40306?
CVE-2025-40306 has a CVSS score of 7.8/10 (HIGH severity). The EPSS model estimates a 0.19% probability of exploitation in the next 30 days.
How do I fix CVE-2025-40306?
Check the vendor references and advisories linked above for patched versions and mitigation guidance. You can also run a Strix scan to test if your systems are affected.

How Strix Helps

Related CVEs from 2025

View all 2025CVEs →

Are you affected by CVE-2025-40306?

Run a free Strix scan to check your systems for this vulnerability.

Scan your code now

Source: NVD / NIST