GPU VulnDB

Database/Kernel, userspace & hypervisor

Linux kernel RDMA/rxe: ODP write paths accept read-only pages, letting RDMA traffic overwrite the page cache

CVSS 7.8CVE-2026-98361Kernel, userspace & hypervisorcurated

Impact

rxe_check_pagefault() lost its access-permission test and only checked HMM_PFN_VALID, so a page faulted in read-only satisfies the check and ODP write operations (RDMA WRITE, RDMA READ response, SEND payload, atomics) modify it through kmap without ever breaking copy-on-write. Per the commit message, an unprivileged local user can register an ODP memory region over a PROT_READ file mapping and have incoming RDMA traffic overwrite the page cache of a file it holds only O_RDONLY - including /etc/passwd or a setuid binary. The report puts this in the same primitive class as Dirty COW. On a GPU node that exposes soft-RoCE to tenant workloads, that is a local-user-to-root path on a shared host, and the corruption lands in the page cache where other tenants' processes read it.

Who can reach it

Local user on the host with access to the rdma uverbs devices (no special privilege beyond that) who can register an ODP memory region and drive RDMA traffic at it. Only affects the software RoCE driver (rxe); mlx5 hardware ODP already enforced the HMM_PFN_WRITE invariant.

What to do

Take the stable kernel fix (three stable commits are listed) and reboot each affected node - there is no module-level mitigation short of not loading rxe. Where soft-RoCE is not actually needed, blacklisting the rxe module removes the exposure without a reboot window of its own. The advisory names no single fixed release; match the commit to the stable branch you run.

References

Related entries

All Kernel, userspace & hypervisor entries

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.