NVIDIA/Mellanox ConnectX driver (mlx5_ib ODP invalidation vs MR deregistration race): During deregistration the lkey is
Impact
During deregistration the lkey is revoked in hardware first, but mlx5_ib_invalidate_range() can concurrently post a UMR update for that same freed lkey. The window is a race between a tenant tearing down a memory region and the MMU notifier invalidating a range of it - two paths the tenant drives - operating on a key the hardware has already released. Keys being operated on after revocation is exactly the state in which a stale key can be observed doing work it should no longer be able to do.
Who can reach it
Local, unprivileged. Concurrent munmap/deregistration of an ODP memory region by a tenant process.
What to do
Kernel update serialising revocation against invalidation. No configuration mitigation.
References
Related entries
- GPU Display Driver: Local privesc (race condition)CVE-2025-23279 · GPU Display DriverHigh
- GPU Display Driver: Local privesc (use-after-free)CVE-2025-23280 · GPU Display DriverHigh
- GPU Display Driver: Local privesc (use-after-free)CVE-2025-23281 · GPU Display DriverHigh
- NVIDIA GPU Display Driver - Linux kernel module (nvidia.ko): A race condition in the Linux display driver is winnableCVE-2025-23282 · NVIDIA GPU Display Driver - Linux kernel module (nvidia.ko)High
- NVIDIA/Mellanox ConnectX driver (mlx5 core completion-queue creation defaults): Every CQ created without an explicitCVE-2025-68209 · NVIDIA/Mellanox ConnectX driver (mlx5 core completion-queue creation defaults)High
- vGPU Manager: Guest-to-host escape (use-after-free in GPU context mgmt)CVE-2026-24200 · vGPU ManagerHigh
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.