CVE-2025-39911: i40e: fix IRQ freeing in i40e_vsi_request_irq_msix error path
In the Linux kernel, the following vulnerability has been resolved:
i40e: fix IRQ freeing in i40e_vsi_request_irq_msix error path
If request_irq() in i40e_vsi_request_irq_msix() fails in an iteration
later than the first, the error path wants to free the IRQs requested
so far. However, it uses the wrong dev_id argument for free_irq(), so
it does not free the IRQs correctly and instead triggers the warning:
Trying to free already-free IRQ 173
WARNING: CPU: 25 PID: 1091 at kernel/irq/manage.c:1829 __free_irq+0x192/0x2c0
Modules linked in: i40e(+) [...]
CPU: 25 UID: 0 PID: 1091 Comm: NetworkManager Not tainted 6.17.0-rc1+ #1 PREEMPT(lazy)
Hardware name: [...]
RIP: 0010:__free_irq+0x192/0x2c0
[...]
Call Trace:
<TASK>
free_irq+0x32/0x70
i40e_vsi_request_irq_msix.cold+0x63/0x8b [i40e]
i40e_vsi_request_irq+0x79/0x80 [i40e]
i40e_vsi_open+0x21f/0x2f0 [i40e]
i40e_open+0x63/0x130 [i40e]
__dev_open+0xfc/0x210
__dev_change_flags+0x1fc/0x240
netif_change_flags+0x27/0x70
do_setlink.isra.0+0x341/0xc70
rtnl_newlink+0x468/0x860
rtnetlink_rcv_msg+0x375/0x450
netlink_rcv_skb+0x5c/0x110
netlink_unicast+0x288/0x3c0
netlink_sendmsg+0x20d/0x430
____sys_sendmsg+0x3a2/0x3d0
___sys_sendmsg+0x99/0xe0
__sys_sendmsg+0x8a/0xf0
do_syscall_64+0x82/0x2c0
entry_SYSCALL_64_after_hwframe+0x76/0x7e
[...]
</TASK>
---[ end trace 0000000000000000 ]---
Use the same dev_id for free_irq() as for request_irq().
I tested this with inserting code to fail intentionally.
Security readout for executives and security teams
Plain-English summary
CVE-2025-39911 is a Linux kernel bug in the i40e network driver. When interrupt allocation fails during device startup, the cleanup path can free interrupts with the wrong identifier, causing kernel warnings and incorrect cleanup. The sources do not show remote code execution, privilege escalation, or active exploitation.
Executive priority
Treat this as routine kernel maintenance unless i40e-backed production networking is business-critical or hosts show related kernel warnings. There is no supplied evidence of active exploitation, but affected infrastructure should still receive normal security updates.
Technical view
The issue is in i40e_vsi_request_irq_msix(). If request_irq() fails after earlier successful iterations, free_irq() is called with a dev_id that does not match the original request_irq() dev_id. The kernel fix changes cleanup to use the same dev_id, preventing incorrect IRQ freeing in that error path.
Likely exposure
Exposure is mainly Linux systems running affected kernels with the i40e driver in use. Systems without this driver loaded, without matching network hardware, or already updated to a vendor kernel containing the stable fix are less likely to be exposed.
Exploitation context
The bundle reports no KEV listing and provides no cited evidence of active exploitation. The described condition depends on an IRQ allocation failure during i40e interface startup, so exploitation context appears operationally narrow based on the supplied sources.
Researcher notes
The public description identifies a cleanup bug, not a broadly reachable attack path. Risk assessment is limited by missing CVSS, CWE, and exploitability details. Validation should focus on affected kernel lineage, i40e module usage, and whether vendor packages carry the referenced stable backports.
Mitigation direction
Update affected Linux kernels using vendor-supported packages containing the stable i40e fix.
Review the Debian LTS advisory if managing Debian LTS systems.
Prioritize systems where the i40e driver is loaded or required for production networking.
Follow distribution guidance for maintenance windows and reboot requirements.
Validation and detection
Check whether affected hosts load the i40e kernel module.
Confirm the running kernel includes one of the referenced stable fixes or vendor backports.
Review kernel logs for i40e IRQ cleanup warnings during interface startup.
Verify distribution security advisories mark the installed kernel as fixed.
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-39911 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.
0CVSS vectors
3Timeline events
2ADP providers
10Source links
SSVC decision data
CISA-ADPCISA Coordinator
Timestamp
Version
2.0.3
Exploitation: noneAutomatable: noTechnical Impact: total
Vulnerability timeline
Timeline events are normalized from CVE metadata, CNA source timelines, ADP timelines, and KEV metadata when present.
CVE reservedCVE Program
The CVE ID was reserved by the assigning CNA.
CVE publishedCVE Program
The CVE record was published.
Oct 1, 2025, 07:44 UTC (UTC+00:00)
CVE updatedCVE Program
The CVE record metadata indicates this as the latest update time.