Bug 2516925 (CVE-2026-74390) - CVE-2026-74390 kernel: RDMA/irdma: Fix out-of-bounds write in irdma_copy_user_pgaddrs
Summary: CVE-2026-74390 kernel: RDMA/irdma: Fix out-of-bounds write in irdma_copy_user...
Keywords:
Status: NEW
Alias: CVE-2026-74390
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Product Security DevOps Team
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2026-08-15 06:40 UTC by OSIDB Bzimport
Modified: 2026-08-20 20:22 UTC (History)
2 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed:
Embargoed:


Attachments (Terms of Use)

Description OSIDB Bzimport 2026-08-15 06:40:42 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.