CVE-2025-39988

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> can: etas_es58x: 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 etas_es58x 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, es58x_start_xmit() receives a CAN XL frame which it is not<br /> able to correctly handle and will thus misinterpret it as a CAN(FD)<br /> frame.<br /> <br /> This can result in a buffer overflow. For example, using the es581.4<br /> variant, the frame will be dispatched to es581_4_tx_can_msg(), go<br /> through the last check at the beginning of this function:<br /> <br /> if (can_is_canfd_skb(skb))<br /> return -EMSGSIZE;<br /> <br /> and reach this line:<br /> <br /> memcpy(tx_can_msg-&gt;data, cf-&gt;data, 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!<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 or<br /> CANFD_MTU (depending on the device capabilities). By fixing the root<br /> cause, this prevents the buffer overflow.