RDMA/irdma: Fix OOB read during CQ MR registration
In the Linux kernel, the following vulnerability has been resolved: RDMA/irdma: Fix OOB read during CQ MR registration Sashiko pointed out an unrelated bug during a previous patch: https://sashiko.dev/#/patchset/20260512183852.614045-1-jmoroni%40google.com This change fixes the bug by eliminating the cqmr->split field which was not being set properly and instead just checks the CQ resize feature flag directly. The cqmr->split field essentially tracks whether IRDMA_FEATURE_CQ_RESIZE is set, but it was not being set until CQ creation time, which is _after_ CQ memory registration (the only other place where it is referenced). As a result, it would always be false during MR registration and would therefore cause irdma_handle_q_mem to populate cqmr->shadow even for GEN_2 HW and beyond: cqmr->shadow = (dma_addr_t)arr[req->cq_pages]; The issue is that for GEN_2 and beyond, req->cq_pages may be exactly equal to iwmr->page_cnt and therefore equal to the size of arr, which would cause an OOB read by one.
- Products
- Kernel
- Affected versions
- Not specified
- Fixed versions
- 5.15.212, 6.1.178, 6.12.97, 6.18.40, 6.6.145, 7.1.5
- CVEs
- CVE-2026-74346
- Confirmed fixed CVEs
- Not specified
- Updated in this feed
- 3 Nov 2026, 02:11 UTC · Revision 1
Source evidence
RDMA/irdma: Fix OOB read during CQ MR registration
core-osv · Original sourcePublished 15 Aug 2026, 05:58 UTC
In the Linux kernel, the following vulnerability has been resolved: RDMA/irdma: Fix OOB read during CQ MR registration Sashiko pointed out an unrelated bug during a previous patch: https://sashiko.dev/#/patchset/20260512183852.614045-1-jmoroni%40google.com This change fixes the bug by eliminating the cqmr->split field which was not being set properly and instead just checks the CQ resize feature flag directly. The cqmr->split field essentially tracks whether IRDMA_FEATURE_CQ_RESIZE is set, but it was not being set until CQ creation time, which is _after_ CQ memory registration (the only other place where it is referenced). As a result, it would always be false during MR registration and would therefore cause irdma_handle_q_mem to populate cqmr->shadow even for GEN_2 HW and beyond: cqmr->shadow = (dma_addr_t)arr[req->cq_pages]; The issue is that for GEN_2 and beyond, req->cq_pages may be exactly equal to iwmr->page_cnt and therefore equal to the size of arr, which would cause an OOB read by one.
osv:CVE-2026-74346
Kernel
Fixed versions: 5.15.212, 6.1.178, 6.6.145, 6.12.97, 6.18.40, 7.1.5
Complete source record
{
"id": "7a371e32219360dfed1bc00c8ed00337eb92ae9b54f490db3113fa17673b54bf",
"url": "https://osv.dev/vulnerability/CVE-2026-74346",
"method": "structured",
"payload": {
"kind": "advisory",
"title": "RDMA/irdma: Fix OOB read during CQ MR registration",
"summary": "In the Linux kernel, the following vulnerability has been resolved: RDMA/irdma: Fix OOB read during CQ MR registration Sashiko pointed out an unrelated bug during a previous patch: https://sashiko.dev/#/patchset/20260512183852.614045-1-jmoroni%40google.com This change fixes the bug by eliminating the cqmr->split field which was not being set properly and instead just checks the CQ resize feature flag directly. The cqmr->split field essentially tracks whether IRDMA_FEATURE_CQ_RESIZE is set, but it was not being set until CQ creation time, which is _after_ CQ memory registration (the only other place where it is referenced). As a result, it would always be false during MR registration and would therefore cause irdma_handle_q_mem to populate cqmr->shadow even for GEN_2 HW and beyond: cqmr->shadow = (dma_addr_t)arr[req->cq_pages]; The issue is that for GEN_2 and beyond, req->cq_pages may be exactly equal to iwmr->page_cnt and therefore equal to the size of arr, which would cause an OOB read by one.",
"evidence": "osv:CVE-2026-74346",
"products": [
{
"name": {
"value": "Kernel",
"evidence": "/affected/1/package/name"
},
"prerequisites": [],
"fixed_versions": [
{
"value": "5.15.212",
"evidence": "/affected/1/ranges"
},
{
"value": "6.1.178",
"evidence": "/affected/1/ranges"
},
{
"value": "6.6.145",
"evidence": "/affected/1/ranges"
},
{
"value": "6.12.97",
"evidence": "/affected/1/ranges"
},
{
"value": "6.18.40",
"evidence": "/affected/1/ranges"
},
{
"value": "7.1.5",
"evidence": "/affected/1/ranges"
}
],
"affected_versions": []
}
],
"severity": "unknown",
"structured": {
"id": "CVE-2026-74346",
"aliases": [
"CVE-2026-74346"
],
"affected": [
{
"ranges": [
{
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"type": "GIT",
"events": [
{
"introduced": "b48c24c2d710cf34810c555dcef883a3d35a9c08"
},
{
"fixed": "a80b3b13786e9ab1c52b31a1f16c7d6708fa9220"
},
{
"fixed": "3159c6fac43dc24b34d31971884d98a7a1bf4c4b"
},
{
"fixed": "ad360a31092a870633ec255b96f50181628b4de0"
},
{
"fixed": "d566002de555b18cc395012c5c1cb8682fc6d2a9"
},
{
"fixed": "54cab78df0375196aaec4e3109191653d21751df"
},
{
"fixed": "d5aa82da8f65562da996d184686db9d0ea718b91"
},
{
"fixed": "4385ddd654d90245eeb83b3cb539670ab5c85ba4"
}
]
}
],
"database_specific": {
"source": "https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2026-74346.json"
}
},
{
"ranges": [
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "5.14.0"
},
{
"fixed": "5.15.212"
}
]
},
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "5.16.0"
},
{
"fixed": "6.1.178"
}
]
},
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "6.2.0"
},
{
"fixed": "6.6.145"
}
]
},
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "6.7.0"
},
{
"fixed": "6.12.97"
}
]
},
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "6.13.0"
},
{
"fixed": "6.18.40"
}
]
},
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "6.19.0"
},
{
"fixed": "7.1.5"
}
]
}
],
"package": {
"name": "Kernel",
"ecosystem": "Linux"
},
"database_specific": {
"source": "https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2026-74346.json"
}
}
],
"modified": "2026-10-28T02:30:25.163280389Z",
"provider": "osv",
"references": [
"https://git.kernel.org/stable/c/3159c6fac43dc24b34d31971884d98a7a1bf4c4b",
"https://git.kernel.org/stable/c/4385ddd654d90245eeb83b3cb539670ab5c85ba4",
"https://git.kernel.org/stable/c/54cab78df0375196aaec4e3109191653d21751df",
"https://git.kernel.org/stable/c/a80b3b13786e9ab1c52b31a1f16c7d6708fa9220",
"https://git.kernel.org/stable/c/ad360a31092a870633ec255b96f50181628b4de0",
"https://git.kernel.org/stable/c/d566002de555b18cc395012c5c1cb8682fc6d2a9",
"https://git.kernel.org/stable/c/d5aa82da8f65562da996d184686db9d0ea718b91",
"https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/74xxx/CVE-2026-74346.json",
"https://nvd.nist.gov/vuln/detail/CVE-2026-74346",
"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git"
],
"provider_metadata": {
"cna_assigner": "Linux",
"osv_generated_from": "https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/74xxx/CVE-2026-74346.json"
}
},
"related_cves": [
{
"value": "CVE-2026-74346",
"evidence": "/id"
}
],
"security_relevant": true,
"severity_evidence": null
},
"source_id": "core-osv",
"document_id": 491801,
"published_at": "2026-08-15T05:58:34.606+00:00"
}