Cloudanix VulnDB

CVE-2026-98361

High · 7.8

CVSS

7.8

EPSS

0.1%

Published

Oct 6, 2026

CISA due date

—

Cloudanix analysis

Next patch cycle SSVC: Track

A local user on certain Linux systems with RDMA hardware could overwrite files they are only allowed to read, potentially gaining higher privileges.

Exploitation
Local Privilege
Attacker needs
Low Privilege
Complexity
Low
Impact
Privilege Gain
Component
OS kernel
Class
Authorization Bypass
Remediation
Patch
Effort
Medium
Patch risk
Low

What it actually does

Missing HMM_PFN_WRITE permission check in rxe_check_pagefault() allows RDMA ODP write operations (WRITE, READ response, SEND, atomics) to modify read-only pages via kmap without breaking CoW, enabling unauthorized writes to page cache of PROT_READ mappings.

Why it matters to the business

Local attackers can corrupt system files such as /etc/passwd or setuid binaries, leading to privilege escalation and full host compromise on RDMA-enabled Linux systems; low immediate risk due to niche hardware requirement and lack of known exploitation.

How an attack unfolds

An unprivileged local user registers an ODP MR over a read-only file mapping, triggers incoming RDMA traffic that satisfies only the VALID check, and overwrites the page cache through kmap without CoW, achieving the same primitive as Dirty COW.

How to fix it

Apply the upstream fix restoring the HMM_PFN_WRITE check in rxe_check_pagefault() for all operations except RXE_PAGEFAULT_RDONLY; upgrade to a kernel containing commit 0b261d7c1cd3 plus the restoration change once released in distribution kernels.

How to confirm the fix worked

Confirm presence of the HMM_PFN_WRITE test in rxe_check_pagefault(); verify that write faults against read-only VMAs now return -EPERM instead of looping; test ODP MR registration over PROT_READ mappings succeeds only for reads.

Typical attack path

  1. Obtain local unprivileged access on RDMA-capable host
  2. Map a read-only file (e.g., /etc/passwd) with PROT_READ
  3. Register ODP MR over the mapping
  4. Initiate RDMA write operations from remote peer or loopback
  5. Overwrite page cache contents without triggering CoW or permission denial

How to detect it

Review kernel logs for repeated page-fault loops or -EPERM returns from hmm_vma_fault in rxe paths; inspect RDMA MR registrations from unprivileged processes against read-only mappings; correlate with unusual modifications to system files without corresponding write syscalls.

What your security team should do

  • Prioritize kernel updates on any system exposing RDMA/rxe interfaces
  • Restrict unprivileged RDMA device access via cgroups or permissions until patched
  • Monitor for new kernel releases containing the referenced fix
  • Audit RDMA usage in containers and virtualized environments

The record

In the Linux kernel, the following vulnerability has been resolved: RDMA/rxe: Restore HMM_PFN_WRITE check in ODP write paths Commit 0b261d7c1cd3 ("RDMA/rxe: Break endless pagefault loop for RO pages") dropped the access permission test from rxe_check_pagefault() and left only HMM_PFN_VALID. A page faulted in read-only, for example a page-cache folio behind a PROT_READ 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 O_RDONLY, 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 HMM_PFN_WRITE. Restore it in rxe by requiring HMM_PFN_WRITE in rxe_check_pagefault() for every operation except RXE_PAGEFAULT_RDONLY. A write to a non-writable VMA now fails the one fault attempt with -EPERM from hmm_vma_fault() 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. arch_wb_cache_pmem() 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 packages

Ecosystem Package Introduced Fixed