CVE-2024-26830 Overview
CVE-2024-26830 affects the Linux kernel's i40e Intel Ethernet driver. The vulnerability allows an untrusted Virtual Function (VF) to remove a Media Access Control (MAC) address that was administratively set by the Physical Function (PF). When the PF assigns a MAC address to a VF and the VF interface is subsequently brought down, the driver removes the MAC from filters and zeroes the primary VF MAC. This behavior undermines the administrative policy enforced by the PF and can disrupt network integrity in virtualized environments using SR-IOV.
Critical Impact
An untrusted VF can bypass PF-enforced MAC address policy, clearing the administratively assigned MAC and disrupting network filtering integrity on i40e-based Intel network adapters.
Affected Products
- Linux kernel prior to patched stable releases (containing i40e driver)
- Linux kernel 6.8 release candidates: 6.8-rc1, 6.8-rc2, 6.8-rc3, 6.8-rc4
- Systems using Intel Ethernet Controller XL710/X710 adapters with SR-IOV enabled
Discovery Timeline
- 2024-04-17 - CVE-2024-26830 published to the National Vulnerability Database (NVD)
- 2026-06-17 - Last updated in NVD database
Technical Details for CVE-2024-26830
Vulnerability Analysis
The vulnerability resides in the Intel i40e driver's handling of MAC address removal requests from Virtual Functions. In SR-IOV deployments, the Physical Function represents the trusted host administrative domain, while Virtual Functions are typically exposed to guest workloads that are treated as untrusted.
When an administrator assigns a MAC address to a VF using ip link set <pf> vf <n> mac <address>, that MAC becomes the authoritative primary MAC for the VF. However, when the VF interface transitions to the down state, the guest-side driver issues a request to delete all associated MAC filters. The i40e driver honored this request unconditionally, removing the administratively set MAC and resetting the primary VF MAC to 00:00:00:00:00:00.
This breaks the trust boundary between the PF administrator and the untrusted VF consumer. It also causes the VF to lose the network identity assigned by the host administrator [CWE-noinfo].
Root Cause
The root cause is missing authorization enforcement in the MAC filter deletion path. The driver did not check whether the primary MAC targeted for deletion was administratively assigned by the PF before honoring the untrusted VF's removal request. The upstream fix adds this check and refuses to delete the primary MAC when it was set by the PF, unless the VF is marked as trusted.
Attack Vector
Exploitation requires local access to a guest environment that owns a VF on an i40e-managed adapter. The attack sequence is straightforward: after the PF administrator assigns a MAC to the VF, a local user inside the VF context brings the VF interface down. This triggers the flush of all MAC filters, removing the administratively set primary MAC. The upstream reproducer demonstrates the issue using standard ip link commands to enable SR-IOV, assign a MAC, and toggle the VF interface state.
The vulnerability does not enable arbitrary code execution or information disclosure. Its impact is limited to integrity of the network configuration and availability of network connectivity for the affected VF.
Refer to the upstream commits for the exact patch logic, including Kernel Git Commit d250a81 and Kernel Git Commit 1c98179.
Detection Methods for CVE-2024-26830
Indicators of Compromise
- VF primary MAC address unexpectedly resetting to 00:00:00:00:00:00 after an administratively assigned MAC, visible via ip link show <pf>.
- Kernel log entries from the i40e driver referencing MAC filter deletion events initiated by an untrusted VF.
- Loss of network connectivity or filter mismatches on VFs immediately after guest-initiated interface state changes.
Detection Strategies
- Audit i40e driver version and kernel build against the fixed stable branches listed in the vendor advisories.
- Enumerate SR-IOV configuration across hosts and identify VFs with administratively assigned MACs using ip link show.
- Compare expected VF MAC assignments against runtime state on a scheduled basis to detect unauthorized clearing.
Monitoring Recommendations
- Forward kernel and network subsystem logs to a centralized logging platform and alert on i40e VF MAC state transitions.
- Monitor host-level SR-IOV configuration drift where guest activity precedes changes to VF primary MAC values.
- Track guest workload interface up/down events on hosts running unpatched i40e drivers.
How to Mitigate CVE-2024-26830
Immediate Actions Required
- Update the Linux kernel to a stable release that includes the upstream i40e fix for administratively set VF MAC handling.
- Inventory hosts running Intel XL710/X710 adapters with SR-IOV enabled and prioritize patching for multi-tenant environments.
- Avoid marking untrusted guest VFs as trusted unless explicitly required by workload design.
Patch Information
The fix has been merged into upstream Linux stable branches through the following commits: Kernel Git Commit 1c98179, Kernel Git Commit 73d9629, Kernel Git Commit be14792, and Kernel Git Commit d250a81. Apply the corresponding distribution kernel update from your vendor.
Workarounds
- Where patching is delayed, avoid assigning MAC addresses to untrusted VFs administratively and rely on host-level network policy enforcement instead.
- Restrict local users within guest VMs from executing privileged network interface operations that can trigger VF state transitions.
- Consider disabling SR-IOV on affected i40e interfaces where multi-tenant separation is required and cannot be otherwise assured.
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.
