CVE-2025-39987

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> can: hi311x: 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, hi3110_hard_start_xmit() receives a CAN XL frame which it is<br /> not able to correctly handle and will thus misinterpret it as a CAN<br /> frame. The driver will consume frame-&gt;len as-is with no further<br /> checks.<br /> <br /> This can result in a buffer overflow later on in hi3110_hw_tx() on<br /> this line:<br /> <br /> memcpy(buf + HI3110_FIFO_EXT_DATA_OFF,<br /> frame-&gt;data, frame-&gt;len);<br /> <br /> Here, frame-&gt;len corresponds to the flags field of the CAN XL frame.<br /> In our previous example, we set canxl_frame-&gt;flags to 0xff. Because<br /> the maximum expected length is 8, a buffer overflow of 247 bytes<br /> occurs!<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.