CVE-2025-40306

About vulnerability

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.

Affected product:

Oracle Linux 7 ELS , Ubuntu 20.04 ELS

Affected packages:

kernel-uek @ 5.4.17 (+1 more)

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.