CVE-2025-40306

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