Answer in brief
CVE-2025-37911 records a Unknown severity vulnerability in bnxt_en: Fix out-of-bound memcpy() during ethtool -w. The current sources do not mark it as known exploited. The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
Analysis pending evidence review
HOL Guard separates source facts from reviewed analysis. See the methodology.
Answer in brief
CVE-2025-37911 records a Unknown severity vulnerability in bnxt_en: Fix out-of-bound memcpy() during ethtool -w. The current sources do not mark it as known exploited. The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
Analysis pending evidence review
HOL Guard separates source facts from reviewed analysis. See the methodology.
A CVSS score is not reported in the current record. The current sources do not mark it as known exploited. Treat this as a source-backed prioritization signal, not a statement about your environment.
Analysis status
Analysis pending evidence review
Factual feed record only; HOL analysis is not approved for indexing. Read the methodology.
The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
| Package | Affected range | Fixed version |
|---|---|---|
| Linux/Linuxgeneric | >=c74751f4c39232c31214ec6a3bc1c7e62f5c728b <69b10dd23ab826d0c7f2d9ab311842251978d0c1 || >=c74751f4c39232c31214ec6a3bc1c7e62f5c728b <43292b83424158fa6ec458799f3cb9c54d18c484 || >=c74751f4c39232c31214ec6a3bc1c7e62f5c728b <4d69864915a3a052538e4ba76cd6fd77cfc64ebe || >=c74751f4c39232c31214ec6a3bc1c7e62f5c728b <44807af79efd0d78fa36383dd865ddfe7992c0a6 || >=c74751f4c39232c31214ec6a3bc1c7e62f5c728b <44d81a9ebf0cad92512e0ffdf7412bfe20db66ec || >=c74751f4c39232c31214ec6a3bc1c7e62f5c728b <6b87bd94f34370bbf1dfa59352bed8efab5bf419 || 4bf973a1f84aefb64750bdb3afe72d54de3199d7 || a76837dd731b68cc3b5690470bc9efa2a8e3801a || >=4.19.95 <4.20 || >=5.4.8 <5.5 | 69b10dd23ab826d0c7f2d9ab311842251978d0c1, 43292b83424158fa6ec458799f3cb9c54d18c484, 4d69864915a3a052538e4ba76cd6fd77cfc64ebe, 44807af79efd0d78fa36383dd865ddfe7992c0a6, 44d81a9ebf0cad92512e0ffdf7412bfe20db66ec, 6b87bd94f34370bbf1dfa59352bed8efab5bf419, 4.20, 5.5 |
| Linux/Linuxgeneric | 5.5 | Not reported |
Published upstream
May 20, 2025
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Aug 5, 2026
Evidence: source:cvelist:source_dates:source-dates:recordFirst seen by HOL
Aug 5, 2026
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.
Quoted source text, attributed separately from HOL analysis.
A CVSS score is not reported in the current record. The current sources do not mark it as known exploited. Treat this as a source-backed prioritization signal, not a statement about your environment.
Analysis status
Analysis pending evidence review
Factual feed record only; HOL analysis is not approved for indexing. Read the methodology.
The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
| Package | Affected range | Fixed version |
|---|---|---|
| Linux/Linuxgeneric | >=c74751f4c39232c31214ec6a3bc1c7e62f5c728b <69b10dd23ab826d0c7f2d9ab311842251978d0c1 || >=c74751f4c39232c31214ec6a3bc1c7e62f5c728b <43292b83424158fa6ec458799f3cb9c54d18c484 || >=c74751f4c39232c31214ec6a3bc1c7e62f5c728b <4d69864915a3a052538e4ba76cd6fd77cfc64ebe || >=c74751f4c39232c31214ec6a3bc1c7e62f5c728b <44807af79efd0d78fa36383dd865ddfe7992c0a6 || >=c74751f4c39232c31214ec6a3bc1c7e62f5c728b <44d81a9ebf0cad92512e0ffdf7412bfe20db66ec || >=c74751f4c39232c31214ec6a3bc1c7e62f5c728b <6b87bd94f34370bbf1dfa59352bed8efab5bf419 || 4bf973a1f84aefb64750bdb3afe72d54de3199d7 || a76837dd731b68cc3b5690470bc9efa2a8e3801a || >=4.19.95 <4.20 || >=5.4.8 <5.5 | 69b10dd23ab826d0c7f2d9ab311842251978d0c1, 43292b83424158fa6ec458799f3cb9c54d18c484, 4d69864915a3a052538e4ba76cd6fd77cfc64ebe, 44807af79efd0d78fa36383dd865ddfe7992c0a6, 44d81a9ebf0cad92512e0ffdf7412bfe20db66ec, 6b87bd94f34370bbf1dfa59352bed8efab5bf419, 4.20, 5.5 |
| Linux/Linuxgeneric | 5.5 | Not reported |
Published upstream
May 20, 2025
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Aug 5, 2026
Evidence: source:cvelist:source_dates:source-dates:recordFirst seen by HOL
Aug 5, 2026
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.
Quoted source text, attributed separately from HOL analysis.