<?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://vulnerability.circl.lu</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>Mon, 28 Sep 2026 20:48:03 +0000</lastBuildDate>
    <item>
      <title>CVE-2025-39985 — can: mcba_usb: populate ndo_change_mtu() to prevent buffer overflow</title>
      <link>https://vulnerability.circl.lu/vuln/cve-2025-39985</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;can: mcba_usb: populate ndo_change_mtu() to prevent buffer overflow&lt;/p&gt;
&lt;p&gt;Sending an PF_PACKET allows to bypass the CAN framework logic and to
directly reach the xmit() function of a CAN driver. The only check
which is performed by the PF_PACKET framework is to make sure that
skb-&amp;gt;len fits the interface&amp;#39;s MTU.&lt;/p&gt;
&lt;p&gt;Unfortunately, because the mcba_usb driver does not populate its
net_device_ops-&amp;gt;ndo_change_mtu(), it is possible for an attacker to
configure an invalid MTU by doing, for example:&lt;/p&gt;
&lt;p&gt;$ ip link set can0 mtu 9999&lt;/p&gt;
&lt;p&gt;After doing so, the attacker could open a PF_PACKET socket using the
ETH_P_CANXL protocol:&lt;/p&gt;
&lt;p&gt;socket(PF_PACKET, SOCK_RAW, htons(ETH_P_CANXL))&lt;/p&gt;
&lt;p&gt;to inject a malicious CAN XL frames. For example:&lt;/p&gt;
&lt;p&gt;struct canxl_frame frame = {
		.flags = 0xff,
		.len = 2048,
	};&lt;/p&gt;
&lt;p&gt;The CAN drivers&amp;#39; xmit() function are calling can_dev_dropped_skb() to
check that the skb is valid, unfortunately under above conditions, the
malicious packet is able to go through can_dev_dropped_skb() checks:&lt;/p&gt;
&lt;p&gt;1. the skb-&amp;gt;protocol is set to ETH_P_CANXL which is valid (the
     function does not check the actual device capabilities).&lt;/p&gt;
&lt;p&gt;2. the length is a valid CAN XL length.&lt;/p&gt;
&lt;p&gt;And so, mcba_usb_start_xmit() receives a CAN XL frame which it is not
able to correctly handle and will thus misinterpret it as a CAN frame.&lt;/p&gt;
&lt;p&gt;This can result in a buffer overflow. The driver will consume cf-&amp;gt;len
as-is with no further checks on these lines:&lt;/p&gt;
&lt;p&gt;usb_msg.…&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;can: mcba_usb: populate ndo_change_mtu() to prevent buffer overflow&lt;/p&gt;
&lt;p&gt;Sending an PF_PACKET allows to bypass the CAN framework logic and to
directly reach the xmit() function of a CAN driver. The only check
which is performed by the PF_PACKET framework is to make sure that
skb-&amp;gt;len fits the interface&amp;#39;s MTU.&lt;/p&gt;
&lt;p&gt;Unfortunately, because the mcba_usb driver does not populate its
net_device_ops-&amp;gt;ndo_change_mtu(), it is possible for an attacker to
configure an invalid MTU by doing, for example:&lt;/p&gt;
&lt;p&gt;$ ip link set can0 mtu 9999&lt;/p&gt;
&lt;p&gt;After doing so, the attacker could open a PF_PACKET socket using the
ETH_P_CANXL protocol:&lt;/p&gt;
&lt;p&gt;socket(PF_PACKET, SOCK_RAW, htons(ETH_P_CANXL))&lt;/p&gt;
&lt;p&gt;to inject a malicious CAN XL frames. For example:&lt;/p&gt;
&lt;p&gt;struct canxl_frame frame = {
		.flags = 0xff,
		.len = 2048,
	};&lt;/p&gt;
&lt;p&gt;The CAN drivers&amp;#39; xmit() function are calling can_dev_dropped_skb() to
check that the skb is valid, unfortunately under above conditions, the
malicious packet is able to go through can_dev_dropped_skb() checks:&lt;/p&gt;
&lt;p&gt;1. the skb-&amp;gt;protocol is set to ETH_P_CANXL which is valid (the
     function does not check the actual device capabilities).&lt;/p&gt;
&lt;p&gt;2. the length is a valid CAN XL length.&lt;/p&gt;
&lt;p&gt;And so, mcba_usb_start_xmit() receives a CAN XL frame which it is not
able to correctly handle and will thus misinterpret it as a CAN frame.&lt;/p&gt;
&lt;p&gt;This can result in a buffer overflow. The driver will consume cf-&amp;gt;len
as-is with no further checks on these lines:&lt;/p&gt;
&lt;p&gt;usb_msg.…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/cve-2025-39985</guid>
    </item>
  </channel>
</rss>
