Your RSA-2048 keys break in 2030. Find every one of them before attackers do.

CVE-2026-46325

CRITICAL

In the Linux kernel, the following vulnerability has been resolved: RDMA/rxe: Fix iova-to-va conversion for MR page sizes != PAGE_SIZE The current implementation incorrectly handles…

Published
Jun 9, 2026
Updated
Jun 17, 2026
Affected
0 pkgs
Patched
None yet
Exploits
None indexed

EPSS Exploitation Probability

via FIRST.org ↗
0.3%probability of exploitation in next 30 days
Lower Risk27th percentile0.00%

EPSS (Exploit Prediction Scoring System) is a daily probability model maintained by FIRST.org. It estimates the likelihood a CVE will be exploited in production environments within the next 30 days, derived from real-world threat intelligence signals.

Description

In the Linux kernel, the following vulnerability has been resolved:

RDMA/rxe: Fix iova-to-va conversion for MR page sizes != PAGE_SIZE

The current implementation incorrectly handles memory regions (MRs) with page sizes different from the system PAGE_SIZE. The core issue is that rxe_set_page() is called with mr->page_size step increments, but the page_list stores individual struct page pointers, each representing PAGE_SIZE of memory.

ib_sg_to_page() has ensured that when i>=1 either a) SG[i-1].dma_end and SG[i].dma_addr are contiguous or b) SG[i-1].dma_end and SG[i].dma_addr are mr->page_size aligned.

This leads to incorrect iova-to-va conversion in scenarios:

  1. page_size < PAGE_SIZE (e.g., MR: 4K, system: 64K): ibmr->iova = 0x181800 sg[0]: dma_addr=0x181800, len=0x800 sg[1]: dma_addr=0x173000, len=0x1000

    Access iova = 0x181800 + 0x810 = 0x182010 Expected VA: 0x173010 (second SG, offset 0x10) Before fix:

    • index = (0x182010 >> 12) - (0x181800 >> 12) = 1
    • page_offset = 0x182010 & 0xFFF = 0x10
    • xarray[1] stores system page base 0x170000
    • Resulting VA: 0x170000 + 0x10 = 0x170010 (wrong)

  2. page_size > PAGE_SIZE (e.g., MR: 64K, system: 4K): ibmr->iova = 0x18f800 sg[0]: dma_addr=0x18f800, len=0x800 sg[1]: dma_addr=0x170000, len=0x1000

    Access iova = 0x18f800 + 0x810 = 0x190010 Expected VA: 0x170010 (second SG, offset 0x10) Before fix:

    • index = (0x190010 >> 16) - (0x18f800 >> 16) = 1
    • page_offset = 0x190010 & 0xFFFF = 0x10
    • xarray[1] stores system page for dma_addr 0x170000
    • Resulting VA: system page of 0x170000 + 0x10 = 0x170010 (wrong)

Yi Zhang reported a kernel panic[1] years ago related to this defect.

Solution:

  1. Replace xarray with pre-allocated rxe_mr_page array for sequential indexing (all MR page indices are contiguous)
  2. Each rxe_mr_page stores both struct page* and offset within the system page
  3. Handle MR page_size != PAGE_SIZE relationships:
    • page_size > PAGE_SIZE: Split MR pages into multiple system pages
    • page_size <= PAGE_SIZE: Store offset within system page
  4. Add boundary checks and compatibility validation

This ensures correct iova-to-va conversion regardless of MR page size and system PAGE_SIZE relationship, while improving performance through array-based sequential access.

Tests on 4K and 64K PAGE_SIZE hosts:

  • rdma-core/pytests $ ./build/bin/run_tests.py --dev eth0_rxe
  • blktest: $ TIMEOUT=30 QUICK_RUN=1 USE_RXE=1 NVMET_TRTYPES=rdma ./check nvme srp rnbd

[1] https://lore.kernel.org/all/CAHj4cs9XRqE25jyVw9rj9YugffLn5+f=1znaBEnu1usLOciD+g@mail.gmail.com/T/

Detection & mitigation playbook

Vulnerability

  1. Detect

    Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for the affected component. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.

  2. Remediation status

    No patched version of the affected component has shipped for CVE-2026-46325 yet. Where your build allows, override or pin the dependency away from the vulnerable range, and apply any maintainer-recommended mitigation.

  3. Mitigate without a patch

    If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.

  4. How O3 protects you

    O3 pinpoints whether CVE-2026-46325 is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.

Tailored to CVE-2026-46325. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.

Frequently Asked Questions

In the Linux kernel, the following vulnerability has been resolved: RDMA/rxe: Fix iova-to-va conversion for MR page sizes != PAGE_SIZE The current implementation incorrectly handles memory regions (MRs) with page sizes different from the system PAGE_SIZE. The core issue is that rxe_set_page() is called with mr->page_size step increments, but the page_list stores individual struct page pointers, each representing PAGE_SIZE of memory. ib_sg_to_page() has ensured that when i>=1 either a) SG[i-1].dma_end and SG[i].dma_addr are contiguous or b) SG[i-1].dma_end and SG[i].dma_addr are mr->page_siz
O3 Security · Impact-Aware SCA

Is CVE-2026-46325 in your dependencies?

O3 detects CVE-2026-46325 across dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.

Scan my dependencies How O3 SCA works
CVE-2026-46325: critical severity vulnerability (CVSS 9.8) | O3 Security