CVE-2025-39810: bnxt_en: Fix memory corruption when FW resources change during ifdown
In the Linux kernel, the following vulnerability has been resolved:
bnxt_en: Fix memory corruption when FW resources change during ifdown
bnxt_set_dflt_rings() assumes that it is always called before any TC has
been created. So it doesn't take bp->num_tc into account and assumes
that it is always 0 or 1.
In the FW resource or capability change scenario, the FW will return
flags in bnxt_hwrm_if_change() that will cause the driver to
reinitialize and call bnxt_cancel_reservations(). This will lead to
bnxt_init_dflt_ring_mode() calling bnxt_set_dflt_rings() and bp->num_tc
may be greater than 1. This will cause bp->tx_ring[] to be sized too
small and cause memory corruption in bnxt_alloc_cp_rings().
Fix it by properly scaling the TX rings by bp->num_tc in the code
paths mentioned above. Add 2 helper functions to determine
bp->tx_nr_rings and bp->tx_nr_rings_per_tc.
Security readout for executives and security teams
Plain-English summary
A flaw in the Linux bnxt_en network driver can corrupt kernel memory when firmware resources change while an interface is being shut down. Successful exploitation requires local, low-privileged access, but could compromise confidentiality, integrity, and availability. Systems not using this driver are unlikely to be exposed.
Executive priority
Prioritize remediation on production, multi-tenant, or locally accessible hosts using bnxt_en. Treat other systems as inventory and verification work rather than assuming fleet-wide exposure. Because kernel memory corruption can enable full host impact, patch promptly after confirming vendor-supported packages and operational compatibility.
Technical view
During driver reinitialization, bnxt_set_dflt_rings() can under-allocate the TX ring array when multiple traffic classes exist. Later allocation in bnxt_alloc_cp_rings() can write beyond that array. The kernel fix scales TX-ring counts by bp->num_tc and introduces helpers for total and per-traffic-class ring counts.
Likely exposure
Exposure is concentrated on affected Linux kernels actively using bnxt_en, particularly where multiple traffic classes are configured and firmware resource or capability changes occur during interface shutdown. The supplied version list includes 5.4, 6.12.45, 6.16.5, and 6.17, but its range semantics are incomplete; confirm status with the kernel or distribution vendor.
Exploitation context
The CVSS vector indicates local access, low privileges, low complexity, and no user interaction. The source bundle does not establish active exploitation, public exploit availability, or inclusion in CISA KEV. Triggering also appears dependent on bnxt_en driver state, multiple traffic classes, and a firmware resource or capability change during interface shutdown.
Researcher notes
CWE-787 and CVSS 7.8 are consistent with an out-of-bounds kernel write. The vulnerable path follows firmware change flags through reinitialization and reservation cancellation into default ring-mode setup. The provided data does not map each stable commit to a specific release branch, so commit ancestry and distribution backports require vendor verification.
Mitigation direction
Apply a vendor-supported kernel containing the referenced bnxt_en correction.
Check Linux distribution advisories for backported fixes and exact affected package versions.
Prioritize systems using bnxt_en with multiple traffic classes.
Restrict local access and unnecessary privileges until patched.
Follow vendor guidance if immediate kernel replacement is unavailable.
Validation and detection
Inventory kernel versions and determine whether bnxt_en is loaded and actively used.
Compare installed kernel changelogs against CVE-2025-39810 and the referenced fix commits.
Identify systems configured with more than one traffic class.
Confirm patched systems booted into the corrected kernel.
Monitor affected hosts for kernel crashes or memory-corruption symptoms during interface 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.
cwe · low confidence lookup
CWE-787: Exact CWE lookup
Use the exact CWE identifier as the starting point before reviewing related ATT&CK behavior. Open the exact CWE lookup page first, then review the ATT&CK searches from that MITRE weakness context. This is a Glexia lookup hint, not an official ATT&CK mapping.
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.
2CVSS vectors
3Timeline events
1ADP providers
4Source links
SSVC decision data
CISA-ADPCISA Coordinator
Timestamp
Version
2.0.3
Exploitation: noneAutomatable: noTechnical Impact: total
CVSS vector scores
2 official scores
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.
CWE links open Glexia weakness intelligence pages with official CWE context, developer remediation guidance, and related CVE mappings.
CWE-787 · source CWE mapping
Out-of-bounds Write
Out-of-bounds Write represents a recurring weakness pattern that can create exploitable paths when design, validation, or implementation controls are missing.