CVE-2025-37911

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bnxt_en: Fix out-of-bound memcpy() during ethtool -w<br /> <br /> When retrieving the FW coredump using ethtool, it can sometimes cause<br /> memory corruption:<br /> <br /> BUG: KFENCE: memory corruption in __bnxt_get_coredump+0x3ef/0x670 [bnxt_en]<br /> Corrupted memory at 0x000000008f0f30e8 [ ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ] (in kfence-#45):<br /> __bnxt_get_coredump+0x3ef/0x670 [bnxt_en]<br /> ethtool_get_dump_data+0xdc/0x1a0<br /> __dev_ethtool+0xa1e/0x1af0<br /> dev_ethtool+0xa8/0x170<br /> dev_ioctl+0x1b5/0x580<br /> sock_do_ioctl+0xab/0xf0<br /> sock_ioctl+0x1ce/0x2e0<br /> __x64_sys_ioctl+0x87/0xc0<br /> do_syscall_64+0x5c/0xf0<br /> entry_SYSCALL_64_after_hwframe+0x78/0x80<br /> <br /> ...<br /> <br /> This happens when copying the coredump segment list in<br /> bnxt_hwrm_dbg_dma_data() with the HWRM_DBG_COREDUMP_LIST FW command.<br /> The info-&gt;dest_buf buffer is allocated based on the number of coredump<br /> segments returned by the FW. The segment list is then DMA&amp;#39;ed by<br /> the FW and the length of the DMA is returned by FW. The driver then<br /> copies this DMA&amp;#39;ed segment list to info-&gt;dest_buf.<br /> <br /> In some cases, this DMA length may exceed the info-&gt;dest_buf length<br /> and cause the above BUG condition. Fix it by capping the copy<br /> length to not exceed the length of info-&gt;dest_buf. The extra<br /> DMA data contains no useful information.<br /> <br /> This code path is shared for the HWRM_DBG_COREDUMP_LIST and the<br /> HWRM_DBG_COREDUMP_RETRIEVE FW commands. The buffering is different<br /> for these 2 FW commands. To simplify the logic, we need to move<br /> the line to adjust the buffer length for HWRM_DBG_COREDUMP_RETRIEVE<br /> up, so that the new check to cap the copy length will work for both<br /> commands.