{
  "schema_version": "1.6.1",
  "id": "RPI-CVE-2026-46181",
  "modified": "2026-10-09T11:39:44Z",
  "upstream": [
    "CVE-2026-46181"
  ],
  "published": "2026-05-28T09:36:53Z",
  "summary": "RDMA/mlx4: Fix mis-use of RCU in mlx4_srq_event()",
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/mlx4: Fix mis-use of RCU in mlx4_srq_event()\n\nSashiko points out the radix_tree itself is RCU safe, but nothing ever\nfrees the mlx4_srq struct with RCU, and it isn't even accessed within the\nRCU critical section. It also will crash if an event is delivered before\nthe srq object is finished initializing.\n\nUse the spinlock since it isn't easy to make RCU work, use\nrefcount_inc_not_zero() to protect against partially initialized objects,\nand order the refcount_set() to be after the srq is fully initialized.",
  "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": null,
            "compiled_filter": false
          }
        }
      }
    }
  ],
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-46181"
    },
    {
      "type": "FIX",
      "url": "https://git.kernel.org/stable/c/1e2a44875b6afb4add1115f7f3351dcbeb6f273d"
    },
    {
      "type": "FIX",
      "url": "https://git.kernel.org/stable/c/8b7833f3bce35cb0d01c1503781523c099c675f0"
    },
    {
      "type": "FIX",
      "url": "https://git.kernel.org/stable/c/c9341307ea16b9395c2e4c9c94d8499d91fe31d0"
    }
  ],
  "database_specific": {
    "source": "https://git.kernel.org/pub/scm/linux/security/vulns.git",
    "upstream_modified": "2026-08-05T13:16:28Z",
    "severity": {
      "source": "kernel CNA",
      "cvss_v3_score": 7.8,
      "cvss_v3_severity": "High",
      "scenario": "AV:L - The race's controllable side (SRQ create/destroy) is driven by local user space through the RDMA verbs interface (/dev/infiniband/uverbsN); a purely remote RDMA peer can generate events but cannot control SRQ lifecycle on the target, so exploitation requires local device access.\nAC:L - The attacker drives both sides \u2014 repeatedly creating/arming/destroying SRQs while keeping them at their limit watermark to make events fire \u2014 so the UAF/partial-init race is winnable through repetition rather than depending on conditions outside the attacker's control.\nPR:L - Creating/destroying SRQs requires access to the RDMA device node but not root or CAP_SYS_ADMIN; unprivileged users routinely have such access under the user-space RDMA model, so low privileges suffice.\nUI:N - The attacker performs all SRQ allocation, arming, and teardown themselves; no action by another user is required.\nS:U - The use-after-free and any resulting corruption stay within the kernel's own security authority; no VM/IOMMU/sandbox boundary is crossed.\nC:H - A use-after-free lets the attacker reallocate the freed mlx4_srq with controlled contents that are then read (refcount, srq->event pointer), enabling kernel memory disclosure.\nI:H - The handler performs refcount manipulation and an indirect call through srq->event on freed/reallocated memory, giving a control-flow-hijack / arbitrary-write primitive typical of UAF.\nA:H - Triggering the bug reliably causes a kernel crash \u2014 NULL/garbage function-pointer dereference for the partially-initialized case and oops/panic for the use-after-free."
    }
  }
}