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. Askeyis 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 xattrkey started working right, xfstest generic/069 exposed an xattr related memory leak that lead to OOM. xattrkey returns a hashed key. When adding xattrs to the orangefs xattr cache, orangefs used hashadd, a kernel hashing macro. hashadd 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 hashadd to hlistadd_head instead and the memory leak ceased and generic/069 quit throwing furniture.
{
"osv_generated_from": "https://github.com/CVEProject/cvelistV5/tree/main/cves/2025/40xxx/CVE-2025-40306.json",
"cna_assigner": "Linux"
}