CVE-2026-92495

What it actually does

The flaw allows a read-only mmap of DBR or toggle pages to retain VM_MAYWRITE, so a later mprotect(PROT_WRITE) succeeds and bypasses the write-permission check that only runs at mmap time.

Why it matters to the business

Systems using RDMA with the bnxt_re driver could be exposed to unauthorized writes into kernel-mapped pages, raising the risk of local privilege escalation or memory corruption on servers that rely on this hardware.

How an attack unfolds

An attacker with local access maps the DBR or toggle page read-only, then calls mprotect to add write permission; because VM_MAYWRITE was never cleared, the kernel permits the write that should have been rejected.

How to fix it

Upgrade the Linux kernel to a version containing the commit that clears VM_MAYWRITE before vm_insert_page in the shared DBR/toggle-page branch of bnxt_re_mmap.

How to confirm the fix worked

Inspect the bnxt_re_mmap function in the running kernel source or binary to confirm VM_MAYWRITE is cleared on the DBR and TOGGLE_PAGE paths; test that mprotect(PROT_WRITE) on a read-only mapping now fails.

Typical attack path

1. Obtain local execution on a host using bnxt_re RDMA
2. Issue mmap for DBR_PAGE or TOGGLE_PAGE with read-only flags
3. Call mprotect(PROT_WRITE) on the resulting mapping
4. Perform writes that should have been blocked

How to detect it

Review audit logs or eBPF traces for mprotect calls that change protection on mappings created by bnxt_re; correlate with processes that also performed DBR or toggle page mmaps.

What your security team should do

• Prioritize kernel updates on any hosts exposing RDMA interfaces
• Restrict local user access on systems that use bnxt_re until patched
• Audit RDMA-enabled workloads for unnecessary user privileges