CVE Catalog

CVE-2025-40306

HighCVSS 7.8
Published: Updated: Translated: NVD NIST

Exploitation Probability (EPSS)

Low risk
0.14%

4th percentile - higher than 4% of all known CVEs

Summary

In the Linux kernel's OrangeFS (orangefs) filesystem driver, a buffer overflow vulnerability was found in extended attribute (xattr) handling. The helper function `xattr_key()` incorrectly checks the loop condition, causing an infinite loop and potential system hang. Additionally, incorrect use of the `hash_add` macro led to memory leaks and unfreed allocations.

Risk Assessment

An attacker can exploit this vulnerability to cause a denial of service (DoS) by hanging a kernel thread or exhausting memory (OOM), destabilizing the system and user applications.

Recommendation

Immediately update the Linux kernel to a version containing the fix (commit in the stable branch). If an update is not possible, temporarily restrict access to the OrangeFS filesystem or disable extended attribute support.

Other vulnerabilities in Linux kernel

See all
Original NVD description (English source)

In the Linux kernel, the following vulnerability has been resolved: orangefs: fix xattr related buffer overflow... Willy Tarreau <[email protected]> forwarded me a message from Disclosure <[email protected]> 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.

Vulnerability data from NVD (NIST) · CISA KEV · EPSS