CVE-2025-37911: bnxt_en: Fix out-of-bound memcpy() during ethtool -w
In the Linux kernel, the following vulnerability has been resolved:
bnxt_en: Fix out-of-bound memcpy() during ethtool -w
When retrieving the FW coredump using ethtool, it can sometimes cause
memory corruption:
BUG: KFENCE: memory corruption in __bnxt_get_coredump+0x3ef/0x670 [bnxt_en]
Corrupted memory at 0x000000008f0f30e8 [ ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ] (in kfence-#45):
__bnxt_get_coredump+0x3ef/0x670 [bnxt_en]
ethtool_get_dump_data+0xdc/0x1a0
__dev_ethtool+0xa1e/0x1af0
dev_ethtool+0xa8/0x170
dev_ioctl+0x1b5/0x580
sock_do_ioctl+0xab/0xf0
sock_ioctl+0x1ce/0x2e0
__x64_sys_ioctl+0x87/0xc0
do_syscall_64+0x5c/0xf0
entry_SYSCALL_64_after_hwframe+0x78/0x80
...
This happens when copying the coredump segment list in
bnxt_hwrm_dbg_dma_data() with the HWRM_DBG_COREDUMP_LIST FW command.
The info->dest_buf buffer is allocated based on the number of coredump
segments returned by the FW. The segment list is then DMA'ed by
the FW and the length of the DMA is returned by FW. The driver then
copies this DMA'ed segment list to info->dest_buf.
In some cases, this DMA length may exceed the info->dest_buf length
and cause the above BUG condition. Fix it by capping the copy
length to not exceed the length of info->dest_buf. The extra
DMA data contains no useful information.
This code path is shared for the HWRM_DBG_COREDUMP_LIST and the
HWRM_DBG_COREDUMP_RETRIEVE FW commands. The buffering is different
for these 2 FW commands. To simplify the logic, we need to move
the line to adjust the buffer length for HWRM_DBG_COREDUMP_RETRIEVE
up, so that the new check to cap the copy length will work for both
commands.
Security readout for executives and security teams
Plain-English summary
A flaw in the Linux bnxt_en network driver can corrupt kernel memory when a local user retrieves a firmware core dump through ethtool. Successful triggering could compromise confidentiality, integrity, or availability. It is not remotely exploitable under the supplied CVSS vector, and exposure depends on the driver and vulnerable kernel code being present.
Executive priority
Treat as an urgent patching item for affected multi-user or shared Linux systems using bnxt_en. Prioritize based on local-user access and driver use rather than internet exposure. For systems without bnxt_en, validate non-exposure and handle through normal kernel maintenance.
Technical view
Firmware can return a DMA length larger than the destination allocated for the core-dump segment list. The driver then performs an out-of-bounds memcpy in __bnxt_get_coredump. The correction caps the copy to the destination length and adjusts shared buffering logic for the COREDUMP_LIST and COREDUMP_RETRIEVE commands.
Likely exposure
Most relevant to systems running an affected Linux kernel with bnxt_en loaded and where a low-privileged local user can reach the ethtool firmware-dump path. Systems without this driver or vulnerable code path are unlikely to be exposed. The supplied version data is complex, so distribution-specific status should be verified.
Exploitation context
The supplied CVSS 3.1 score is 7.8 with local access, low complexity, low privileges, and no user interaction. Potential impact is high across confidentiality, integrity, and availability. The bundle marks KEV false and provides no evidence of active exploitation or a public exploit.
Researcher notes
The source describes kernel memory corruption caused by an oversized firmware-reported DMA length. No CWE is supplied. Although the CVSS impact ratings are high, the bundle does not establish reliable exploitation, affected hardware scope, or observed attacks. Kernel and distribution backports must be assessed by patch presence, not version strings alone.
Mitigation direction
Install a vendor-supported kernel containing the referenced stable fix.
Verify distribution advisories because backported fixes may not match upstream version numbers.
Prioritize multi-user systems where untrusted local accounts can access relevant network administration interfaces.
Until patched, limit access to firmware core-dump functionality where operationally feasible.
Validation and detection
Inventory kernel builds and determine whether bnxt_en is installed, loaded, or actively used.
Compare each kernel package against vendor advisories and the referenced stable fixes.
Confirm the deployed driver caps copy length to the allocated destination buffer.
Review kernel logs for bnxt_en core-dump failures, KFENCE corruption, crashes, or unexplained instability.
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-37911 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.
1CVSS vectors
3Timeline events
1ADP providers
8Source links
CVSS vector scores
1 official score
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.