{
  "schema_version": "1.6.1",
  "id": "RPI-CVE-2026-74390",
  "modified": "2026-10-09T11:39:44Z",
  "upstream": [
    "CVE-2026-74390"
  ],
  "published": "2026-08-15T06:04:33Z",
  "summary": "RDMA/irdma: Fix out-of-bounds write in irdma_copy_user_pgaddrs",
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/irdma: Fix out-of-bounds write in irdma_copy_user_pgaddrs\n\nThe irdma_copy_user_pgaddrs function loops through all of the umem DMA\nblocks to populate the PBLEs and will stop when either the last DMA\nblock is reached or palloc->total_cnt is reached. The issue is that\nthe logic for checking palloc->total_cnt would only work for non-zero\nvalues.\n\nWhen irdma_setup_pbles is called with lvl==0, it\ncalls irdma_copy_user_pgaddrs with palloc->total_cnt==0, which means\nthe only way to break out of the loop is to reach the last umem DMA\nblock, which means it could end up going beyond the fixed size of 4\niwmr->pgaddrmem array that is used in the lvl==0 case.\n\nIn the case of QP/CQ/SRQ rings, the value of lvl is determined by a\nseparate input (for example, req.cq_pages in the case of a CQ). So,\nwe must perform explicit checking to ensure we don't overflow the\npgaddrmem array if the user provides a umem that consists of more\nblocks than their provided req.cq_pages.",
  "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.178",
            "compiled_filter": false
          }
        }
      }
    }
  ],
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-74390"
    },
    {
      "type": "FIX",
      "url": "https://git.kernel.org/stable/c/4780f58672ee6328accd54a95f9c00683477e499"
    },
    {
      "type": "FIX",
      "url": "https://git.kernel.org/stable/c/79a20a8e201a779224b4bf115250a7713bde72c0"
    },
    {
      "type": "FIX",
      "url": "https://git.kernel.org/stable/c/9f8f0d2099e3de1194e37dc933ae0c4206b09aaf"
    },
    {
      "type": "FIX",
      "url": "https://git.kernel.org/stable/c/192a3be0e3759daa24af2841208b074ca6dbaabc"
    },
    {
      "type": "FIX",
      "url": "https://git.kernel.org/stable/c/424d51d33c7541a86934067c2c0538124687fc90"
    },
    {
      "type": "FIX",
      "url": "https://git.kernel.org/stable/c/abd27a977b419d584efa659488c22d2306987b29"
    },
    {
      "type": "FIX",
      "url": "https://git.kernel.org/stable/c/5ebb3ed757be3e04cf803026004aa0beaeb13e9b"
    }
  ],
  "database_specific": {
    "source": "https://git.kernel.org/pub/scm/linux/security/vulns.git",
    "upstream_modified": "2026-08-17T05:50:24Z",
    "severity": {
      "source": "kernel CNA",
      "cvss_v3_score": 7.8,
      "cvss_v3_severity": "High",
      "scenario": "AV:L - Exploitation requires a local ioctl on /dev/infiniband/uverbs to register CQ/QP/SRQ memory via irdma_reg_user_mr; the bug is not reachable from remote iWARP/RoCE packet handling.\nAC:L - An attacker fully controls reg_type, cq_pages/sq_pages/rq_pages, and umem size; triggering lvl==0 with many DMA blocks is deterministic and needs no races or special memory layout.\nPR:L - Any unprivileged local user who can open the uverbs device (mode 0666) and use the RDMA NIC\u2014typical on cloud/HPC RDMA nodes\u2014can invoke the vulnerable MR registration path without real root.\nUI:N - No victim interaction is required; the attacker triggers the overflow directly through their own RDMA verbs memory registration calls.\nS:U - Impact is kernel heap corruption and privilege escalation within the host kernel security boundary, not a cross-VM or cross-IOMMU sandbox escape.\nC:H - The out-of-bounds write of attacker-influenced DMA addresses into adjacent irdma_mr/iwpbl heap metadata can be leveraged for arbitrary kernel memory read primitives, not merely a bounded leak.\nI:H - Controlled out-of-bounds u64 writes past pgaddrmem[4] corrupt adjacent kernel heap structures and are suitable for control-flow or arbitrary kernel write exploitation.\nA:H - Heap corruption in a kzalloc'd irdma_mr can cause immediate kernel oops/panic during registration or on subsequent use of corrupted queue memory metadata."
    }
  }
}