Answer in brief
CVE-2026-74346 records a Unknown severity vulnerability in RDMA/irdma: Fix OOB read during CQ MR registration. The current sources do not mark it as known exploited. The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
Analysis pending evidence review
HOL Guard separates source facts from reviewed analysis. See the methodology.
Answer in brief
CVE-2026-74346 records a Unknown severity vulnerability in RDMA/irdma: Fix OOB read during CQ MR registration. The current sources do not mark it as known exploited. The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
Analysis pending evidence review
HOL Guard separates source facts from reviewed analysis. See the methodology.
A CVSS score is not reported in the current record. The current sources do not mark it as known exploited. Treat this as a source-backed prioritization signal, not a statement about your environment.
Analysis status
Analysis pending evidence review
Factual feed record only; HOL analysis is not approved for indexing. Read the methodology.
The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
| Package | Affected range | Fixed version |
|---|---|---|
| Linux/Linuxgeneric | >=b48c24c2d710cf34810c555dcef883a3d35a9c08 <a80b3b13786e9ab1c52b31a1f16c7d6708fa9220 || >=b48c24c2d710cf34810c555dcef883a3d35a9c08 <3159c6fac43dc24b34d31971884d98a7a1bf4c4b || >=b48c24c2d710cf34810c555dcef883a3d35a9c08 <ad360a31092a870633ec255b96f50181628b4de0 || >=b48c24c2d710cf34810c555dcef883a3d35a9c08 <d566002de555b18cc395012c5c1cb8682fc6d2a9 || >=b48c24c2d710cf34810c555dcef883a3d35a9c08 <54cab78df0375196aaec4e3109191653d21751df || >=b48c24c2d710cf34810c555dcef883a3d35a9c08 <d5aa82da8f65562da996d184686db9d0ea718b91 || >=b48c24c2d710cf34810c555dcef883a3d35a9c08 <4385ddd654d90245eeb83b3cb539670ab5c85ba4 | a80b3b13786e9ab1c52b31a1f16c7d6708fa9220, 3159c6fac43dc24b34d31971884d98a7a1bf4c4b, ad360a31092a870633ec255b96f50181628b4de0, d566002de555b18cc395012c5c1cb8682fc6d2a9, 54cab78df0375196aaec4e3109191653d21751df, d5aa82da8f65562da996d184686db9d0ea718b91, 4385ddd654d90245eeb83b3cb539670ab5c85ba4 |
| Linux/Linuxgeneric | 5.14 | Not reported |
Published upstream
Aug 15, 2026
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Aug 15, 2026
Evidence: source:cvelist:source_dates:source-dates:recordFirst seen by HOL
Aug 15, 2026
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.
Quoted source text, attributed separately from HOL analysis.
A CVSS score is not reported in the current record. The current sources do not mark it as known exploited. Treat this as a source-backed prioritization signal, not a statement about your environment.
Analysis status
Analysis pending evidence review
Factual feed record only; HOL analysis is not approved for indexing. Read the methodology.
The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
| Package | Affected range | Fixed version |
|---|---|---|
| Linux/Linuxgeneric | >=b48c24c2d710cf34810c555dcef883a3d35a9c08 <a80b3b13786e9ab1c52b31a1f16c7d6708fa9220 || >=b48c24c2d710cf34810c555dcef883a3d35a9c08 <3159c6fac43dc24b34d31971884d98a7a1bf4c4b || >=b48c24c2d710cf34810c555dcef883a3d35a9c08 <ad360a31092a870633ec255b96f50181628b4de0 || >=b48c24c2d710cf34810c555dcef883a3d35a9c08 <d566002de555b18cc395012c5c1cb8682fc6d2a9 || >=b48c24c2d710cf34810c555dcef883a3d35a9c08 <54cab78df0375196aaec4e3109191653d21751df || >=b48c24c2d710cf34810c555dcef883a3d35a9c08 <d5aa82da8f65562da996d184686db9d0ea718b91 || >=b48c24c2d710cf34810c555dcef883a3d35a9c08 <4385ddd654d90245eeb83b3cb539670ab5c85ba4 | a80b3b13786e9ab1c52b31a1f16c7d6708fa9220, 3159c6fac43dc24b34d31971884d98a7a1bf4c4b, ad360a31092a870633ec255b96f50181628b4de0, d566002de555b18cc395012c5c1cb8682fc6d2a9, 54cab78df0375196aaec4e3109191653d21751df, d5aa82da8f65562da996d184686db9d0ea718b91, 4385ddd654d90245eeb83b3cb539670ab5c85ba4 |
| Linux/Linuxgeneric | 5.14 | Not reported |
Published upstream
Aug 15, 2026
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Aug 15, 2026
Evidence: source:cvelist:source_dates:source-dates:recordFirst seen by HOL
Aug 15, 2026
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.
Quoted source text, attributed separately from HOL analysis.