CVE-2024-26830: i40e: Do not allow untrusted VF to remove administratively set MAC
In the Linux kernel, the following vulnerability has been resolved:
i40e: Do not allow untrusted VF to remove administratively set MAC
Currently when PF administratively sets VF's MAC address and the VF
is put down (VF tries to delete all MACs) then the MAC is removed
from MAC filters and primary VF MAC is zeroed.
Do not allow untrusted VF to remove primary MAC when it was set
administratively by PF.
Reproducer:
1) Create VF
2) Set VF interface up
3) Administratively set the VF's MAC
4) Put VF interface down
[root@host ~]# echo 1 > /sys/class/net/enp2s0f0/device/sriov_numvfs
[root@host ~]# ip link set enp2s0f0v0 up
[root@host ~]# ip link set enp2s0f0 vf 0 mac fe:6c:b5:da:c7:7d
[root@host ~]# ip link show enp2s0f0
23: enp2s0f0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
link/ether 3c:ec:ef:b7:dd:04 brd ff:ff:ff:ff:ff:ff
vf 0 link/ether fe:6c:b5:da:c7:7d brd ff:ff:ff:ff:ff:ff, spoof checking on, link-state auto, trust off
[root@host ~]# ip link set enp2s0f0v0 down
[root@host ~]# ip link show enp2s0f0
23: enp2s0f0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
link/ether 3c:ec:ef:b7:dd:04 brd ff:ff:ff:ff:ff:ff
vf 0 link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff, spoof checking on, link-state auto, trust off
Security readout for executives and security teams
Plain-English summary
An untrusted virtual network function can remove a MAC address that the host administrator assigned, undermining network policy and potentially disrupting connectivity. The issue affects integrity and availability, not confidentiality, and requires local low-privilege access to the virtual function.
Executive priority
Prioritize affected multi-tenant, virtualized, and network-sensitive hosts because an untrusted workload could disrupt connectivity or weaken administrator-enforced addressing. Systems without i40e SR-IOV virtual functions are unlikely to be exposed. Patch through supported vendor channels after compatibility testing.
Technical view
The Linux i40e driver incorrectly permits an untrusted SR-IOV virtual function to delete its primary, PF-administered MAC when the VF is brought down. This removes the MAC filter and resets the primary VF MAC to zero, crossing the PF/VF trust boundary.
Likely exposure
Exposure is limited to Linux systems using the i40e driver with SR-IOV virtual functions on affected kernels. Risk is greatest where tenants, guests, containers, or other untrusted workloads can control a VF whose MAC is administratively assigned by the physical function.
Exploitation context
The supplied CVSS rates exploitation as local, low complexity, low privilege, and requiring no user interaction. CISA KEV status is false, and the supplied sources provide no evidence of active exploitation. Exploitation requires control of an affected untrusted VF.
Researcher notes
The security boundary is between the privileged physical function and an untrusted virtual function. The corrected behavior prevents the VF from deleting a primary MAC established administratively by the PF. The bundle lists affected versions but does not provide complete distribution-specific package mappings; validate against vendor advisories and commit inclusion.
Mitigation direction
Update to a vendor-supported kernel containing the referenced i40e stable fix.
Review distribution or appliance vendor guidance for the applicable corrected kernel package.
Restrict untrusted workload access to i40e SR-IOV virtual functions until patched.
Monitor administratively assigned VF MAC addresses for unexpected clearing or zeroing.
Validation and detection
Inventory systems using the i40e driver and enabled SR-IOV virtual functions.
Identify kernel versions and compare them with vendor advisories and referenced stable fixes.
Confirm untrusted VFs cannot remove PF-administratively assigned primary MAC addresses.
Verify assigned VF MAC filters persist through normal VF interface state changes.
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-2024-26830 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.
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.