CVE-2025-39987 can: hi311x: populate ndo_change_mtu() to prevent buffer overflow

High 7.8 Published Updated

A local attacker can trigger a buffer overflow in the hi311x CAN driver by setting an invalid MTU and sending malicious CAN XL frames, potentially leading to code execution or system crash.

Exploited in the wild
Not known
Login needed
Any signed-in user
Attackable
Local or same network only
Victim action needed
Not needed
Fix
Available

What is CVE-2025-39987?

CVE-2025-39987 is a high-severity memory corruption vulnerability in Linux, published on 15 Oct 2025. It can only be exploited from the same machine or local network, with no action from the victim.

Official description

In the Linux kernel, the following vulnerability has been resolved:

can: hi311x: populate ndo_change_mtu() to prevent buffer overflow

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->len fits the interface's MTU.

Unfortunately, because the sun4i_can driver does not populate its net_device_ops->ndo_change_mtu(), it is possible for an attacker to configure an invalid MTU by doing, for example:

$ ip link set can0 mtu 9999

After doing so, the attacker could open a PF_PACKET socket using the ETH_P_CANXL protocol:

socket(PF_PACKET, SOCK_RAW, htons(ETH_P_CANXL))

to inject a malicious CAN XL frames. For example:

struct canxl_frame frame = { .flags = 0xff, .len = 2048, };

The CAN drivers' 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:

1. the skb->protocol is set to ETH_P_CANXL which is valid (the function does not check the actual device capabilities).

2. the length is a valid CAN XL length.

And so, hi3110_hard_start_xmit() receives a CAN XL frame which it is not able to correctly handle and will thus misinterpret it as a CAN frame. The driver will consume frame->len as-is with no further checks.

This can result in a buffer overflow later on in hi3110_hw_tx() on this line:

memcpy(buf + HI3110_FIFO_EXT_DATA_OFF, frame->data, frame->len);

Here, frame->len corresponds to the flags field of the CAN XL frame. In our previous example, we set canxl_frame->flags to 0xff. Because the maximum expected length is 8, a buffer overflow of 247 bytes occurs!

Populate net_device_ops->ndo_change_mtu() to ensure that the interface's MTU can not be set to anything bigger than CAN_MTU. By fixing the root cause, this prevents the buffer overflow.

Which versions are affected by CVE-2025-39987?

How do I fix CVE-2025-39987?

Apply the vendor's patch.

Upgrade to the fixed version. Memory-safe languages, compiler hardening and fuzzing prevent most new cases. More about Memory corruption.

Is CVE-2025-39987 being exploited?

There is no known exploitation of CVE-2025-39987 in the wild and no public exploit code.

Sources

Also known as AZL-68516, BELL-CVE-2025-39987, DEBIAN-CVE-2025-39987, GHSA-j555-7g4r-x4w9, ROOT-OS-DEBIAN-11-CVE-2025-39987, ROOT-OS-DEBIAN-12-CVE-2025-39987 and 3 more.

Is CVE-2025-39987 in your software?

Upload an SBOM and sbomify checks it against every vulnerability here, every day.

Check your SBOMs for free