CVE-2026-72045 is a confused-deputy vulnerability in the Cavium Octeon TX2 AF mailbox handler for LMTLINE table setup. The bug isn't a missing check — it's a trust conflation: the dispatcher validates that a request came from an authenticated PCI function, then treats the base_pcifunc payload field as implicitly authorized within that function's context. A VF authenticated as function X can request that the driver map function Y's LMTLINE base address into X's table entry, bypassing all isolation between VFs under the same PF.
The fix restricts sharing to functions under the same PF — but this leaves residual blast radius. A compromised VF can still nominate any sibling VF's LMTLINE, not just its own. The legitimate use case for intra-PF VF-to-VF borrowing is unclear, and the more defensible position is that no VF should be able to claim another VF's resources through this interface. That fix would force inter-function LMTLINE allocation through explicit PF-mediated provisioning rather than peer-to-peer mailbox requests.
The deeper problem is architectural: this interface exposes raw PCI function indices as request parameters rather than wrapping them in capability tokens. This is the same confused-deputy pattern that has recurred across SR-IOV implementations — Intel VT-d, Mellanox BlueField, NVIDIA vGPU — where authenticated-source identity gets conflated with authorization for payload-provided target indices. The institutional knowledge exists but doesn't transfer between vendors or kernel subsystems.
Worse, this is a persistent-state vulnerability, not a transient one. The LMT map table retains entries across VF lifecycle events. A malicious VF that exploited this before the patch didn't just make a one-off request — it wrote values into other functions' table entries that may persist through VF teardown and reprovisioning. Patching the kernel and rebooting may be insufficient; you likely need a PF-level reset to scrub stale mappings. The CVSS 8.8 score reflects confidentiality and integrity impact, but LMTLINE is a write gate, not a read gate — exploitation enables cross-tenant DMA writes into another VF's memory region, which is categorically worse than information disclosure.
For incident response: identify whether any VFs were reprovisioned between the vulnerability window and the patch. If so, audit the LMT map table state for unexpected cross-VF entries. The remediation sequence also has organizational inertia — the fix constrains VF requests to intra-PF sharing, which means PF firmware must be updated before VF-side changes are meaningful. In shared hosting environments where tenants control different VFs under the same PF, this is a cross-tenant vulnerability requiring the PF operator to act first.