CVE-2025-40104: ixgbevf: fix mailbox API compatibility by negotiating supported features
In the Linux kernel, the following vulnerability has been resolved:
ixgbevf: fix mailbox API compatibility by negotiating supported features
There was backward compatibility in the terms of mailbox API. Various
drivers from various OSes supporting 10G adapters from Intel portfolio
could easily negotiate mailbox API.
This convention has been broken since introducing API 1.4.
Commit 0062e7cc955e ("ixgbevf: add VF IPsec offload code") added support
for IPSec which is specific only for the kernel ixgbe driver. None of the
rest of the Intel 10G PF/VF drivers supports it. And actually lack of
support was not included in the IPSec implementation - there were no such
code paths. No possibility to negotiate support for the feature was
introduced along with introduction of the feature itself.
Commit 339f28964147 ("ixgbevf: Add support for new mailbox communication
between PF and VF") increasing API version to 1.5 did the same - it
introduced code supported specifically by the PF ESX driver. It altered API
version for the VF driver in the same time not touching the version
defined for the PF ixgbe driver. It led to additional discrepancies,
as the code provided within API 1.6 cannot be supported for Linux ixgbe
driver as it causes crashes.
The issue was noticed some time ago and mitigated by Jake within the commit
d0725312adf5 ("ixgbevf: stop attempting IPSEC offload on Mailbox API 1.5").
As a result we have regression for IPsec support and after increasing API
to version 1.6 ixgbevf driver stopped to support ESX MBX.
To fix this mess add new mailbox op asking PF driver about supported
features. Basing on a response determine whether to set support for IPSec
and ESX-specific enhanced mailbox.
New mailbox op, for compatibility purposes, must be added within new API
revision, as API version of OOT PF & VF drivers is already increased to
1.6 and doesn't incorporate features negotiate op.
Features negotiation mechanism gives possibility to be extended with new
features when needed in the future.
Security readout for executives and security teams
Plain-English summary
A compatibility failure in Linux’s ixgbevf virtual network driver can enable unsupported mailbox features between Intel 10GbE physical and virtual functions. Certain driver combinations may crash or lose IPsec or ESX mailbox functionality. Risk is concentrated in virtualized systems using this hardware and driver, not ordinary Linux hosts without ixgbevf.
Executive priority
Treat as high priority for virtualization infrastructure using Intel 10GbE SR-IOV and ixgbevf, especially where untrusted tenants receive virtual functions. Other systems have low likely exposure. Patch during the next expedited maintenance window after confirming vendor applicability; investigate immediately if mailbox-related crashes or network instability are already occurring.
Technical view
Mailbox API versions 1.4 through 1.6 implied capabilities that some PF drivers did not implement. ixgbevf could consequently activate incompatible IPsec or ESX-enhanced mailbox behavior. The resolution introduces explicit PF feature negotiation. CVSS 3.1 scores this 7.8 with local access, low privileges, low complexity, no user interaction, and high potential confidentiality, integrity, and availability impact.
Likely exposure
Most likely exposure is a Linux guest or virtualized host using the ixgbevf VF driver with an Intel 10GbE adapter and an incompatible PF implementation. The supplied version data identifies affected Linux releases but is ambiguous about ranges and backports; distribution-specific advisories should determine whether an installed kernel contains a fix.
Exploitation context
The CVSS vector describes a local, low-privileged attack path requiring no user interaction. The supplied sources document crashes and compatibility regressions, but provide no confirmed exploitation mechanism. The CVE is not listed as KEV, and this bundle contains no evidence of active exploitation or a public exploit.
Researcher notes
The core defect is capability inference from mailbox API versions instead of explicit feature negotiation. Historical changes introduced Linux-specific IPsec and ESX-specific enhanced mailbox behavior without interoperable negotiation. The bundle does not identify a CWE, proven exploit primitive, affected adapter models, or precise distribution package boundaries. Avoid equating the CVSS impact ratings with demonstrated data compromise.
Mitigation direction
Install a vendor-supported kernel containing the applicable stable fix or an equivalent distribution backport.
Prioritize virtualized systems using ixgbevf with Intel 10GbE SR-IOV virtual functions.
Check Linux distribution advisories because package versions may include fixes through backports.
Where immediate updating is impossible, consult vendor guidance before changing VF, IPsec, or mailbox configurations.
Validation and detection
Inventory systems for loaded or configured ixgbevf virtual-function drivers.
Identify the physical-function driver and mailbox API combination used by each exposed virtual function.
Confirm the running kernel package contains the relevant upstream fix or distribution backport.
After updating, test network stability and required IPsec or ESX mailbox functionality.
Monitor kernel and driver logs for mailbox negotiation failures, resets, or crashes.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cve · low confidence lookup
CVE-2025-40104 mapping review
Open the CVE-to-ATT&CK bridge for reviewed, inferred, or future official mappings tied to this CVE.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.
1CVSS vectors
3Timeline events
0ADP providers
6Source links
CVSS vector scores
1 official score
We collect every scored CVSS vector available in the official CNA and ADP containers. When more than one version is present, the table keeps the source vectors side by side instead of collapsing them into the highest score.