# CVE-2025-40104: ixgbevf: fix mailbox API compatibility by negotiating supported features > A compatibility issue in the ixgbevf driver causes crashes when negotiating mailbox API features, leading to denial of service. - **Severity:** High 7.8 (`CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H`) - **Exploited in the wild:** Not known - **Login needed:** Any signed-in user - **Attackable:** Local or same network only - **Victim action needed:** Not needed - **Fix available:** Yes - **Published:** 30 Oct 2025 - **Updated:** 15 Oct 2026 - **Also known as:** AZL-69400, BELL-CVE-2025-40104, DEBIAN-CVE-2025-40104, GHSA-326q-28hh-wvjc, ROOT-OS-DEBIAN-11-CVE-2025-40104, ROOT-OS-DEBIAN-12-CVE-2025-40104, ROOT-OS-DEBIAN-13-CVE-2025-40104, ROOT-OS-UBUNTU-2204-CVE-2025-40104, ROOT-OS-UBUNTU-2404-CVE-2025-40104, UBUNTU-CVE-2025-40104 ## What is CVE-2025-40104? CVE-2025-40104 is a high-severity vulnerability in Linux, published on 30 Oct 2025. It can only be exploited from the same machine or local network, with no action from the victim. ### Official description 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. ## Which versions are affected by CVE-2025-40104? ## How do I fix CVE-2025-40104? Apply the vendor's patch. ## Is CVE-2025-40104 being exploited? There is no known exploitation of CVE-2025-40104 in the wild and no public exploit code. ## Fix prompt for AI coding agents ```text Check this codebase for CVE-2025-40104 and fix it if it is affected. What it is: CVE-2025-40104 is a high-severity vulnerability in Linux, published on 30 Oct 2025. It can only be exploited from the same machine or local network, with no action from the victim. Exploitation: There is no known exploitation of CVE-2025-40104 in the wild and no public exploit code. Affected product: Linux. No package-level version data is available, so check the vendor advisory linked from the reference page. Task: 1. Search the dependency manifests and lockfiles (for example package.json, package-lock.json, requirements.txt, poetry.lock, uv.lock, pom.xml, build.gradle, go.mod, Cargo.lock, Gemfile.lock) and any Dockerfiles for the affected packages, including transitive dependencies. 2. If an affected version is in use, upgrade it to the fixed version for its release line with the project's package manager, so the lockfile is regenerated. Prefer the smallest upgrade that fixes it. 3. If there is no fix, or the upgrade would break the build, do not guess: explain the risk and the safest workaround instead. 4. Run the tests and summarise what changed and why. 5. If nothing in the project is affected, say so and change nothing. Reference: https://insights.sbomify.com/CVE-2025-40104/ (Markdown: https://insights.sbomify.com/CVE-2025-40104/index.md) ``` ## Sources - CVE record: https://www.cve.org/CVERecord?id=CVE-2025-40104 - NVD: https://nvd.nist.gov/vuln/detail/CVE-2025-40104 - OSV: https://osv.dev/vulnerability/CVE-2025-40104 --- From sbomify Insights: https://insights.sbomify.com/CVE-2025-40104/ Summaries are generated and may contain mistakes; the official description above is the record.