CVE-2026-72045 in Linux
Summary
by MITRE • 08/15/2026
In the Linux kernel, the following vulnerability has been resolved:
octeontx2-af: cn10k: restrict VF LMTLINE sharing to its own PF
rvu_mbox_handler_lmtst_tbl_setup() uses req->base_pcifunc as a direct index into the LMT map table to read another function's LMTLINE physical base address and copy it into the caller's own LMT map table entry. The mailbox dispatcher authenticates req->hdr.pcifunc from the IRQ source, but req->base_pcifunc is a separate payload field and is not sanitized.
Reject the request with -EPERM when a VF caller's base_pcifunc is not a valid function under its own PF. is_pf_func_valid() bounds the FUNC field to the PF's configured VF count, keeping the computed index inside the caller's own slot block.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 08/23/2026
The Linux kernel driver for Cavium OcteonTX2 and CN10K network interfaces contains a critical access control vulnerability within the mailbox handler function rvu_mbox_handler_lmtst_tbl_setup. This flaw stems from an improper validation of input parameters provided by virtual functions, allowing unauthorized memory mapping operations that can compromise system integrity. The specific issue arises because the driver uses the base_pcifunc field from the request payload as a direct index into the LMT (Local Memory Table) map table to retrieve physical base addresses belonging to other PCI functions. While the mailbox dispatcher correctly authenticates the header pcifunc against the IRQ source, it fails to sanitize or validate the separate base_pcifunc field contained within the message body. This discrepancy creates an opportunity for a malicious virtual function to bypass intended isolation boundaries by specifying arbitrary function identifiers in its request payload.
From a technical perspective, this vulnerability represents a classic case of insufficient input validation leading to improper access control. The driver assumes that any valid PCI function identifier provided in the base_pcifunc field belongs to the requesting entity's parent physical function. However, without explicit bounds checking against the configured virtual function count for that specific PF, an attacker can craft requests that reference LMTLINE entries belonging to other physical functions or unrelated hardware components. By copying these foreign physical addresses into its own LMT map table entry, a compromised or malicious VF gains indirect access to memory regions it should not be able to reach. This effectively breaks the virtualization isolation model provided by SR-IOV and similar technologies, allowing potential data exfiltration or denial of service through unauthorized memory manipulation.
The operational impact of this vulnerability is severe in multi-tenant environments where multiple virtual functions share a single physical function on OcteonTX2 hardware. An attacker with access to a vulnerable VF can potentially read sensitive kernel memory structures mapped by other PFs, leading to information disclosure vulnerabilities classified under CWE-200: Information Exposure. Furthermore, if the accessed LMT entries correspond to writable regions or critical system resources, the attacker could modify these areas, resulting in privilege escalation or system instability categorized as CWE-787: Out-of-bounds Write or CWE-119: Improper Restriction of Operations within the Bounds of a Memory Buffer. In cloud infrastructure contexts, this flaw undermines tenant isolation guarantees and violates fundamental security principles regarding resource partitioning.
To mitigate this risk, developers have implemented a strict validation check using the is_pf_func_valid() function before processing the request. This routine ensures that the base_pcifunc field corresponds to a valid virtual function within the scope of the caller's parent physical function by bounding the FUNC field against the PF's configured VF count. If the specified function does not fall within this allowed range, the driver immediately rejects the request with an -EPERM error code, preventing unauthorized access attempts. This fix aligns with security best practices for handling untrusted input in kernel-space drivers and addresses the root cause by enforcing proper access control checks on all user-supplied parameters regardless of their position within the message structure.
This vulnerability is associated with CWE-284: Improper Access Control, as it involves a failure to enforce intended restrictions on resource access. Additionally, from an adversary behavior perspective, this flaw facilitates techniques described in MITRE ATT&CK under T1074: Data Staged or T1560: Archive Collected Data if the attacker uses the unauthorized memory access for data staging and exfiltration. It also relates to T1059: Command and Scripting Interpreter scenarios where kernel-level exploitation is required for persistent control. System administrators should ensure that their Linux kernels are updated with patches addressing this specific OcteonTX2 driver issue, particularly in environments running workloads on CN10K or similar hardware architectures where SR-IOV virtualization is actively utilized. Regular auditing of PCI device configurations and monitoring for anomalous mailbox traffic patterns can further enhance detection capabilities while patching efforts are deployed across the infrastructure.