CVE-2025-37911

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 __bnxtgetcoredump+0x3ef/0x670 [bnxt_en] Corrupted memory at 0x000000008f0f30e8 [ ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ] (in kfence-#45): __bnxtgetcoredump+0x3ef/0x670 [bnxten] ethtoolgetdumpdata+0xdc/0x1a0 __devethtool+0xa1e/0x1af0 devethtool+0xa8/0x170 devioctl+0x1b5/0x580 sockdoioctl+0xab/0xf0 sockioctl+0x1ce/0x2e0 __x64sysioctl+0x87/0xc0 dosyscall64+0x5c/0xf0 entrySYSCALL64afterhwframe+0x78/0x80

...

This happens when copying the coredump segment list in bnxthwrmdbgdmadata() with the HWRMDBGCOREDUMPLIST FW command. The info->destbuf 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->destbuf length and cause the above BUG condition. Fix it by capping the copy length to not exceed the length of info->destbuf. The extra DMA data contains no useful information.

This code path is shared for the HWRMDBGCOREDUMPLIST and the HWRMDBGCOREDUMPRETRIEVE 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 HWRMDBGCOREDUMP_RETRIEVE up, so that the new check to cap the copy length will work for both commands.