CVE-2025-39986

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> can: sun4i_can: populate ndo_change_mtu() to prevent buffer overflow<br /> <br /> Sending an PF_PACKET allows to bypass the CAN framework logic and to<br /> directly reach the xmit() function of a CAN driver. The only check<br /> which is performed by the PF_PACKET framework is to make sure that<br /> skb-&gt;len fits the interface&amp;#39;s MTU.<br /> <br /> Unfortunately, because the sun4i_can driver does not populate its<br /> net_device_ops-&gt;ndo_change_mtu(), it is possible for an attacker to<br /> configure an invalid MTU by doing, for example:<br /> <br /> $ ip link set can0 mtu 9999<br /> <br /> After doing so, the attacker could open a PF_PACKET socket using the<br /> ETH_P_CANXL protocol:<br /> <br /> socket(PF_PACKET, SOCK_RAW, htons(ETH_P_CANXL))<br /> <br /> to inject a malicious CAN XL frames. For example:<br /> <br /> struct canxl_frame frame = {<br /> .flags = 0xff,<br /> .len = 2048,<br /> };<br /> <br /> The CAN drivers&amp;#39; xmit() function are calling can_dev_dropped_skb() to<br /> check that the skb is valid, unfortunately under above conditions, the<br /> malicious packet is able to go through can_dev_dropped_skb() checks:<br /> <br /> 1. the skb-&gt;protocol is set to ETH_P_CANXL which is valid (the<br /> function does not check the actual device capabilities).<br /> <br /> 2. the length is a valid CAN XL length.<br /> <br /> And so, sun4ican_start_xmit() receives a CAN XL frame which it is not<br /> able to correctly handle and will thus misinterpret it as a CAN frame.<br /> <br /> This can result in a buffer overflow. The driver will consume cf-&gt;len<br /> as-is with no further checks on this line:<br /> <br /> dlc = cf-&gt;len;<br /> <br /> Here, cf-&gt;len corresponds to the flags field of the CAN XL frame. In<br /> our previous example, we set canxl_frame-&gt;flags to 0xff. Because the<br /> maximum expected length is 8, a buffer overflow of 247 bytes occurs a<br /> couple line below when doing:<br /> <br /> for (i = 0; i data[i], priv-&gt;base + (dreg + i * 4));<br /> <br /> Populate net_device_ops-&gt;ndo_change_mtu() to ensure that the<br /> interface&amp;#39;s MTU can not be set to anything bigger than CAN_MTU. By<br /> fixing the root cause, this prevents the buffer overflow.