CVE-2026-72312

This vulnerability in the Octeon TX2 (octeontx2-af) driver allows a virtual function (VF) to destructively modify the physical function's (PF) hardware state. When a VF calls the nix_set_rx_mode mailbox handler to change its own receive mode, the underlying APIs—rvu_npc_enable_allmulti_entry() and rvu_npc_enable_promisc_entry()—operate on the PF's MCAM (Match-CAM) rules instead of the VF's. The fix adds is_vf() guards to prevent this cross-context operation, which tells you everything: this was a missing scope check, not a sophisticated flaw. The practical impact is that a compromised VF can delete the PF's promiscuous mode rules, blinding the host's ability to see traffic on that network segment. This isn't a VM-to-VM data leak—it's one workload being able to disable its hypervisor's monitoring tap. The cascade is severe: in a multi-tenant environment, one compromised VM can degrade monitoring for every workload sharing that PF, and in configurations using MACVTAP or SR-IOV passthrough, traffic can flow without inspection during the blind window. The CVSS of 7.9 paired with an EPSS of 0.00154 is misleading. The low probability score reflects that exploitation requires VF access, which makes this a post-compromise persistence or lateral movement vector rather than an initial access bug. That does not reduce the severity—it amplifies it. If an attacker has already compromised a tenant workload, they should not be able to interfere with PF-level hardware. Audit other mbox handlers in this driver for similar missing is_vf() guards. Monitor MCAM rule changes on PF interfaces as a detection signal. In environments where tenants have VF access, treat this as a trust boundary violation: the ability to manipulate PF state from a VF represents a category failure that extends beyond this specific handler.

Reviewed through automated stages and approved by a human before publication.