FKIE_CVE-2025-40306

Vulnerability from fkie_nvd - Published: 2025-12-08 01:16 - Updated: 2025-12-08 18:26
Severity ?
Summary
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. 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.
References
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/025e880759c279ec64d0f754fe65bf45961da864
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/15afebb9597449c444801d1ff0b8d8b311f950ab
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/9127d1e90c90e5960c8bc72a4ce2c209691a7021
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/bc812574de633cf9a9ad6974490e45f6a4bb5126
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/c2ca015ac109fd743fdde27933d59dc5ad46658e
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/c6564ff6b53c9a8dc786b6f1c51ae7688273f931
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/e09a096104fc65859422817fb2211f35855983fe
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/ef892d2bf4f3fa2c8de1677dd307e678bdd3d865
Impacted products
Vendor Product Version
To clipboard 

{
  "cveTags": [],
  "descriptions": [
    {
      "lang": "en",
      "value": "In the Linux kernel, the following vulnerability has been resolved:\n\norangefs: fix xattr related buffer overflow...\n\nWilly Tarreau \u003cw@1wt.eu\u003e forwarded me a message from\nDisclosure \u003cdisclosure@aisle.com\u003e with the following\nwarning:\n\n\u003e The helper `xattr_key()` uses the pointer variable in the loop condition\n\u003e rather than dereferencing it. As `key` is incremented, it remains non-NULL\n\u003e (until it runs into unmapped memory), so the loop does not terminate on\n\u003e valid C strings and will walk memory indefinitely, consuming CPU or hanging\n\u003e the thread.\n\nI easily reproduced this with setfattr and getfattr, causing a kernel\noops, hung user processes and corrupted orangefs files. Disclosure\nsent along a diff (not a patch) with a suggested fix, which I based\nthis patch on.\n\nAfter xattr_key started working right, xfstest generic/069 exposed an\nxattr related memory leak that lead to OOM. xattr_key returns\na hashed key.  When adding xattrs to the orangefs xattr cache, orangefs\nused hash_add, a kernel hashing macro. hash_add also hashes the key using\nhash_log which resulted in additions to the xattr cache going to the wrong\nhash bucket. generic/069 tortures a single file and orangefs does a\ngetattr for the xattr \"security.capability\" every time. Orangefs\nnegative caches on xattrs which includes a kmalloc. Since adds to the\nxattr cache were going to the wrong bucket, every getattr for\n\"security.capability\" resulted in another kmalloc, none of which were\never freed.\n\nI changed the two uses of hash_add to hlist_add_head instead\nand the memory leak ceased and generic/069 quit throwing furniture."
    }
  ],
  "id": "CVE-2025-40306",
  "lastModified": "2025-12-08T18:26:19.900",
  "metrics": {},
  "published": "2025-12-08T01:16:02.820",
  "references": [
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/025e880759c279ec64d0f754fe65bf45961da864"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/15afebb9597449c444801d1ff0b8d8b311f950ab"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/9127d1e90c90e5960c8bc72a4ce2c209691a7021"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/bc812574de633cf9a9ad6974490e45f6a4bb5126"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/c2ca015ac109fd743fdde27933d59dc5ad46658e"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/c6564ff6b53c9a8dc786b6f1c51ae7688273f931"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/e09a096104fc65859422817fb2211f35855983fe"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/ef892d2bf4f3fa2c8de1677dd307e678bdd3d865"
    }
  ],
  "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
  "vulnStatus": "Awaiting Analysis"
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.




Sightings

Author Source Type Date

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.



Detection rules are retrieved from Rulezet.