<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<rss xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/" version="2.0">
  <channel>
    <title>Most recent entries from all</title>
    <link>https://cve.radiocsirt.org</link>
    <description>Contains only the most 10 recent entries.</description>
    <docs>http://www.rssboard.org/rss-specification</docs>
    <generator>python-feedgen</generator>
    <language>en</language>
    <lastBuildDate>Sat, 10 Oct 2026 12:09:25 +0000</lastBuildDate>
    <item>
      <title>CVE-2025-37911 — bnxt_en: Fix out-of-bound memcpy() during ethtool -w</title>
      <link>https://cve.radiocsirt.org/vuln/cve-2025-37911</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Linux&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;bnxt_en: Fix out-of-bound memcpy() during ethtool -w&lt;/p&gt;
&lt;p&gt;When retrieving the FW coredump using ethtool, it can sometimes cause
memory corruption:&lt;/p&gt;
&lt;p&gt;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&lt;/p&gt;
&lt;p&gt;...&lt;/p&gt;
&lt;p&gt;This happens when copying the coredump segment list in
bnxt_hwrm_dbg_dma_data() with the HWRM_DBG_COREDUMP_LIST FW command.
The info-&amp;gt;dest_buf buffer is allocated based on the number of coredump
segments returned by the FW.  The segment list is then DMA&amp;#39;ed by
the FW and the length of the DMA is returned by FW.  The driver then
copies this DMA&amp;#39;ed segment list to info-&amp;gt;dest_buf.&lt;/p&gt;
&lt;p&gt;In some cases, this DMA length may exceed the info-&amp;gt;dest_buf length
and cause the above BUG condition.  Fix it by capping the copy
length to not exceed the length of info-&amp;gt;dest_buf.  The extra
DMA data contains no useful information.&lt;/p&gt;
&lt;p&gt;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 ad…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Linux&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;bnxt_en: Fix out-of-bound memcpy() during ethtool -w&lt;/p&gt;
&lt;p&gt;When retrieving the FW coredump using ethtool, it can sometimes cause
memory corruption:&lt;/p&gt;
&lt;p&gt;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&lt;/p&gt;
&lt;p&gt;...&lt;/p&gt;
&lt;p&gt;This happens when copying the coredump segment list in
bnxt_hwrm_dbg_dma_data() with the HWRM_DBG_COREDUMP_LIST FW command.
The info-&amp;gt;dest_buf buffer is allocated based on the number of coredump
segments returned by the FW.  The segment list is then DMA&amp;#39;ed by
the FW and the length of the DMA is returned by FW.  The driver then
copies this DMA&amp;#39;ed segment list to info-&amp;gt;dest_buf.&lt;/p&gt;
&lt;p&gt;In some cases, this DMA length may exceed the info-&amp;gt;dest_buf length
and cause the above BUG condition.  Fix it by capping the copy
length to not exceed the length of info-&amp;gt;dest_buf.  The extra
DMA data contains no useful information.&lt;/p&gt;
&lt;p&gt;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 ad…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/cve-2025-37911</guid>
    </item>
  </channel>
</rss>
