{
  "schema_version": "1.6.1",
  "id": "RPI-CVE-2025-40306",
  "modified": "2026-10-09T11:39:44Z",
  "upstream": [
    "CVE-2025-40306"
  ],
  "published": "2025-12-08T00:47:38Z",
  "summary": "orangefs: fix xattr related buffer overflow...",
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\norangefs: fix xattr related buffer overflow...\n\nWilly Tarreau <w@1wt.eu> forwarded me a message from\nDisclosure <disclosure@aisle.com> with the following\nwarning:\n\n> The helper `xattr_key()` uses the pointer variable in the loop condition\n> rather than dereferencing it. As `key` is incremented, it remains non-NULL\n> (until it runs into unmapped memory), so the loop does not terminate on\n> valid C strings and will walk memory indefinitely, consuming CPU or hanging\n> 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.",
  "severity": [
    {
      "type": "CVSS_V3",
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H"
    }
  ],
  "affected": [
    {
      "package": {
        "ecosystem": "Raspberry Pi OS:12",
        "name": "linux"
      },
      "versions": [
        "1:6.1.47-1+rpt4"
      ],
      "ecosystem_specific": {
        "binaries": [
          {
            "binary_name": "linux-image-6.1.0-rpi3-rpi-2712",
            "binary_version": "1:6.1.47-1+rpt4"
          },
          {
            "binary_name": "linux-image-6.1.0-rpi3-rpi-v6",
            "binary_version": "1:6.1.47-1+rpt4"
          },
          {
            "binary_name": "linux-image-6.1.0-rpi3-rpi-v7",
            "binary_version": "1:6.1.47-1+rpt4"
          },
          {
            "binary_name": "linux-image-6.1.0-rpi3-rpi-v7l",
            "binary_version": "1:6.1.47-1+rpt4"
          },
          {
            "binary_name": "linux-image-6.1.0-rpi3-rpi-v8",
            "binary_version": "1:6.1.47-1+rpt4"
          }
        ]
      },
      "database_specific": {
        "per_version": {
          "1:6.1.47-1+rpt4": {
            "linux_commit": "655fc658a15ae7a6f37103754adb39ba52a9a14e",
            "upstream_version": "6.1.47",
            "assessment": "commit ancestry (strak rule)",
            "upstream_fixed": "6.1.159",
            "compiled_filter": false
          }
        }
      }
    }
  ],
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://www.cve.org/CVERecord?id=CVE-2025-40306"
    },
    {
      "type": "FIX",
      "url": "https://git.kernel.org/stable/c/c6564ff6b53c9a8dc786b6f1c51ae7688273f931"
    },
    {
      "type": "FIX",
      "url": "https://git.kernel.org/stable/c/ef892d2bf4f3fa2c8de1677dd307e678bdd3d865"
    },
    {
      "type": "FIX",
      "url": "https://git.kernel.org/stable/c/15afebb9597449c444801d1ff0b8d8b311f950ab"
    },
    {
      "type": "FIX",
      "url": "https://git.kernel.org/stable/c/bc812574de633cf9a9ad6974490e45f6a4bb5126"
    },
    {
      "type": "FIX",
      "url": "https://git.kernel.org/stable/c/e09a096104fc65859422817fb2211f35855983fe"
    },
    {
      "type": "FIX",
      "url": "https://git.kernel.org/stable/c/9127d1e90c90e5960c8bc72a4ce2c209691a7021"
    },
    {
      "type": "FIX",
      "url": "https://git.kernel.org/stable/c/c2ca015ac109fd743fdde27933d59dc5ad46658e"
    },
    {
      "type": "FIX",
      "url": "https://git.kernel.org/stable/c/025e880759c279ec64d0f754fe65bf45961da864"
    }
  ],
  "database_specific": {
    "source": "https://git.kernel.org/pub/scm/linux/security/vulns.git",
    "upstream_modified": "2026-08-05T12:19:11Z",
    "severity": {
      "source": "kernel CNA",
      "cvss_v3_score": 7.8,
      "cvss_v3_severity": "High",
      "scenario": "AV:L - The vulnerable `xattr_key()` is reached only through local syscalls (getxattr/setxattr/removexattr, or implicit ACL and `security.capability` lookups) on a mounted OrangeFS filesystem. The xattr keys originate from local userspace or kernel .rodata, never from the OrangeFS server's network responses.\nAC:L - A single `getfattr`/`setfattr` on any file of an OrangeFS mount deterministically triggers the runaway loop; the maintainer reported reproducing it \"easily\". No race, no memory-layout precondition, and the guard-page fault on the kernel stack makes the oops essentially guaranteed.\nPR:L - Any unprivileged local user with read access to a file on the mount can trigger it; `xattr_permission()` only requires MAY_READ for the user.* namespace, and the `.prefix = \"\"` handler matches every name. The ACL/`security.capability` paths fire during ordinary permission checks and execve, needing no explicit privilege at all.\nUI:N - The attacker triggers the bug entirely through their own syscalls with no victim action required. An existing OrangeFS mount is a property of the deployment, not an action the attacker must induce a user to perform.\nS:U - The out-of-bounds read, hang, and oops all occur within the kernel of the same host, with no crossing into another security authority such as a hypervisor or IOMMU boundary.\nC:H - This is an unbounded out-of-bounds read that walks arbitrary kernel memory \u2014 live kernel stack contents, .rodata/.data, or the slab and direct map \u2014 far beyond a few bounded bytes. The resulting hash bucket (`sum % 16`) is observable to the attacker as a cache-hit/miss timing oracle over that adjacent kernel memory.\nI:H - The maintainer directly observed \"corrupted orangefs files\" when reproducing the bug, a confirmed loss of integrity of user data on a shared parallel filesystem. The broken xattr cache additionally governs POSIX ACL and `security.capability` retrieval, so mis-bucketed and stale entries can corrupt access-control and file-capability decisions.\nA:H - Confirmed kernel oops, hung user processes, and OOM from the associated unbounded kmalloc leak. The loop has no `cond_resched()` and runs with `xattr_sem` write-held in the set/remove paths, so it burns a CPU until it faults while blocking every other thread on that inode \u2014 soft lockups, RCU stalls, and hung tasks."
    }
  }
}