CVE-2026-98361: RDMA/rxe: Restore HMM_PFN_WRITE check in ODP write paths
In the Linux kernel, the following vulnerability has been resolved:
RDMA/rxe: Restore HMMPFNWRITE check in ODP write paths
Commit 0b261d7c1cd3 ("RDMA/rxe: Break endless pagefault loop for RO pages") dropped the access permission test from rxecheckpagefault() and left only HMMPFNVALID. A page faulted in read-only, for example a page-cache folio behind a PROTREAD file mapping, then satisfies the check and ODP write operations (RDMA WRITE, RDMA READ response, SEND payload, atomics) modify it through kmap without ever breaking CoW.
An unprivileged user can register an ODP MR over such a mapping and have incoming RDMA traffic overwrite the page cache of a file it only holds ORDONLY, including /etc/passwd or setuid binaries. This is the same primitive class as Dirty COW and CVE-2022-2590.
mlx5 has the missing invariant: its ODP path sets the device write bit only for pfns that carry HMMPFNWRITE. Restore it in rxe by requiring HMMPFNWRITE in rxecheckpagefault() for every operation except RXEPAGEFAULTRDONLY. A write to a non-writable VMA now fails the one fault attempt with -EPERM from hmmvmafault() instead of re-faulting forever. For a writable VMA the fault breaks CoW and the write lands in the private page.
Keep pmem flushes on the read-only check. archwbcachepmem() never modifies memory, and the FLUSH access bits do not make the umem writable, so classifying flushes as writes would make every flush against a flush-only MR fail.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Compensating control
In the RDMA/rxe ODP write paths, restore the HMM_PFN_WRITE check by requiring HMM_PFN_WRITE for operations that modify memory, while keeping pmem flushes on the read-only check.
Event History
Frequently Asked Questions
What conditions are required for exploitation?
An unprivileged user must be able to register an ODP memory region over a read-only mapping. Incoming RDMA traffic must then perform an ODP write-capable operation against that mapping.
Which RDMA operations can trigger the unsafe write path?
The affected ODP write paths include RDMA WRITE, RDMA READ responses, SEND payload handling, and atomic operations. The read-only page-fault operation, RXE_PAGEFAULT_RDONLY, is excluded from the restored write-permission requirement.
What is the practical impact of a successful exploit?
An attacker can modify page-cache-backed file content through a mapping for which it has only read access, without breaking copy-on-write. The advisory specifically notes that this could include files such as /etc/passwd or setuid binaries.
What behavior should occur after the fix when a write targets a non-writable mapping?
The write fault fails with -EPERM from hmm_vma_fault() rather than repeatedly faulting. For writable mappings, the fault breaks copy-on-write as expected.