CVE-2026-74390High· 7.8▾ TwilightIn the Linux kernel, the following vulnerability has been resolved: RDMA/irdma: Fix out-of-bounds write in irdma_copy_user_pgaddrs The irdma_copy_user_pgaddrs function loops through all of the umem DMA blocks to populate the PBLEs and …
▾ Twilight zone — High severity, or a signal on a lesser flaw
impact 42.9 · likelihood 0 · exploitation 0
Need a working PoC? Pro members can cast a request and our team develops one — it lands right here.
Stakeholder-Specific Vulnerability Categorization from CISA's ADP record at CVE.org: whether exploitation is observed, whether an attack can be automated, and how much of the system is at stake. The CVSS score shown above comes from the assigning CNA record, not NVD.
Exploit-prediction probability, daily snapshots since Oct 16.
Disclosure to exploitation, from the record and what we observed since indexing it.
Disclosed via CVEORG
Last analysed / modified upstream
0.1%
In the Linux kernel, the following vulnerability has been resolved:
RDMA/irdma: Fix out-of-bounds write in irdma_copy_user_pgaddrs
The irdma_copy_user_pgaddrs function loops through all of the umem DMA blocks to populate the PBLEs and will stop when either the last DMA block is reached or palloc->total_cnt is reached. The issue is that the logic for checking palloc->total_cnt would only work for non-zero values.
When irdma_setup_pbles is called with lvl==0, it calls irdma_copy_user_pgaddrs with palloc->total_cnt==0, which means the only way to break out of the loop is to reach the last umem DMA block, which means it could end up going beyond the fixed size of 4 iwmr->pgaddrmem array that is used in the lvl==0 case.
In the case of QP/CQ/SRQ rings, the value of lvl is determined by a separate input (for example, req.cq_pages in the case of a CQ). So, we must perform explicit checking to ensure we don't overflow the pgaddrmem array if the user provides a umem that consists of more blocks than their provided req.cq_pages.
Linux >= b48c24c2d710cf34810c555dcef883a3d35a9c08 < 4780f58672ee6328accd54a95f9c00683477e499Linux >= b48c24c2d710cf34810c555dcef883a3d35a9c08 < 79a20a8e201a779224b4bf115250a7713bde72c0Linux >= b48c24c2d710cf34810c555dcef883a3d35a9c08 < 9f8f0d2099e3de1194e37dc933ae0c4206b09aafLinux >= b48c24c2d710cf34810c555dcef883a3d35a9c08 < 192a3be0e3759daa24af2841208b074ca6dbaabcLinux >= b48c24c2d710cf34810c555dcef883a3d35a9c08 < 424d51d33c7541a86934067c2c0538124687fc90Linux >= b48c24c2d710cf34810c555dcef883a3d35a9c08 < abd27a977b419d584efa659488c22d2306987b29Linux >= b48c24c2d710cf34810c555dcef883a3d35a9c08 < 5ebb3ed757be3e04cf803026004aa0beaeb13e9bLinux 5.14Refer to the linked advisories for vendor-supplied fixes and affected version ranges.
Connected by shared product, vendor, weakness, or advisory.
CVE-2024-38564High· 7.8bpf: Add BPF_PROG_TYPE_CGROUP_SKB attach type enforcement in BPF_LINK_CREATE
CVE-2026-99092Noneriscv: patch: fix handling of bpf-jit execmem addresses
CVE-2026-99089NoneASoC: samsung: i2s: enable op_clk in probe to balance runtime PM
CVE-2026-99093Nonemm: don't schedule deferred kernel page table freeing while booting
CVE-2026-99088Nonenet: openvswitch: validate transport header presence in set_ipv6_addr
CVE-2026-99090Nonedrm/amdgpu: serialize vblank counter reads against GPU reset