CVE-2026-72500 is a use-after-free in the bnxt_re RDMA driver where a toggle page is freed before firmware teardown of the SRQ completes, allowing an interrupt handler to write to already-freed memory. The patch moves free_page() after bnxt_qplib_destroy_srq(), which narrows the race window — but be cautious about assuming this eliminates the vulnerability entirely. If destroy_srq() is asynchronous (firmware-managed teardown that returns immediately while background work continues), the window between the call returning and free_page() executing is still exposed. The commit message states 'after firmware teardown completes,' but confirming whether this API actually blocks requires examining the bnxt_qplib contract or firmware behavior — not just accepting the commit message at face value.
What makes this worth deeper attention is the pattern: the same UAF topology has appeared in Mellanox, qed, and i40iw drivers. In each case, a driver developer assumed a destroy call was synchronously complete when it was not. The root cause is not developer incompetence but an API that fails to surface its temporal constraints — the firmware library knows its internal state machine, but the driver calling it has no explicit synchronization hook to know when resources are truly released. The toggle page itself is telling: it exists as legacy infrastructure tracking 'previous' interrupt state, likely added when firmware teardown behavior was poorly specified. That threat model may be obsolete, but the page persists because no one is certain removing it is safe. This is entropy — deprecated infrastructure that nobody certifies, kept precisely because the firmware semantics that originally required it have shifted beneath the code.
For defenders: verify your bnxt_re version includes this commit (check kernel/git/stable/linux.git history for bnxt_re SRQ teardown ordering). But also audit other bnxt_qplib destroy paths — RDMA QP, CQ, and MR teardown likely share the same implicit synchronization assumptions. The deeper question is whether your driver version ships with a toggle page for firmware semantics that no longer apply, creating latent risk beyond this specific CVE. If the bnxt_qplib library does not expose explicit completion callbacks for firmware teardown, treat every destroy call as potentially asynchronous until proven otherwise, and order resource release conservatively.