CVE-2025-40306
Unknown Unknown - Not Provided
BaseFortify

Publication date: 2025-12-08

Last updated on: 2025-12-08

Assigner: kernel.org

Description
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.
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2025-12-08
Last Modified
2025-12-08
Generated
2026-05-07
AI Q&A
2025-12-08
EPSS Evaluated
2026-05-05
NVD
Affected Vendors & Products
Showing 1 associated CPE
Vendor Product Version / Range
orangefs orangefs *
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-UNKNOWN
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?

This vulnerability in the Linux kernel's orangefs component involves a buffer overflow related to extended attributes (xattr). The helper function `xattr_key()` incorrectly uses a pointer variable in a loop condition without dereferencing it, causing the loop to not terminate properly and potentially walk memory indefinitely. This can lead to kernel crashes (kernel oops), hung user processes, and corrupted orangefs files. Additionally, a memory leak was found in the xattr cache due to improper use of the kernel hashing macro `hash_add`, which caused memory allocations that were never freed. The fix involved correcting the loop condition and replacing `hash_add` with `hlist_add_head` to stop the memory leak.


How can this vulnerability impact me? :

This vulnerability can cause serious system instability including kernel crashes, hung user processes, and file corruption within orangefs. It can also lead to memory leaks that may cause the system to run out of memory (OOM), impacting system availability and reliability.


How can this vulnerability be detected on my network or system? Can you suggest some commands?

This vulnerability can be detected by observing kernel oops messages, hung user processes, or corrupted orangefs files when using extended attributes (xattr). Commands such as 'setfattr' and 'getfattr' can be used to test for the vulnerability by attempting to set and get extended attributes on files, which may reproduce the kernel oops or hangs if the system is vulnerable.


What immediate steps should I take to mitigate this vulnerability?

Immediate mitigation involves applying the patch that replaces the use of 'hash_add' with 'hlist_add_head' in the orangefs xattr cache handling to prevent memory leaks and kernel hangs. Until the patch is applied, avoid operations that heavily use extended attributes on orangefs, such as frequent 'getattr' calls for 'security.capability', to reduce the risk of triggering the vulnerability.


Ask Our AI Assistant
Need more information? Ask your question to get an AI reply (Powered by our expertise)
0/70
EPSS Chart