CVE-2025-39986: Linux kernel · can: sun4i_can: populate ndo_change_mtu() to prevent buffer overflow
Affects Linux kernelSource GCVE Database
Not known to be exploited · CVSS 7.8 High · fixed in 5.15.0-1110.119~20.04.1 : patch Linux kernel soon.
Data as of 26 Oct 2026, 14:05 UTC
- EPSS
- 0.1% chance of exploitation in 30 days – higher than 6% of CVEsExploit Prediction Scoring System: the likelihood attackers will use this flaw soon.
- Patch
- Available – fixed in 5.15.0-1110.119~20.04.1, 5.15.0-1100.109~20.04.1, 5.15.0-1100.107~20.04.2 +2
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HExploitation evidence
Disclosed: evidence found.
CVE published 15 Oct 2025
Detectable: no evidence on record.
No public nuclei template indexed
Weaponised: no evidence on record.
No public exploit code indexed in Metasploit or Exploit-DB
Exploited in the wildExploited: no evidence on record.
Not in CISA KEV and no source reports exploitation
Observed by OffSeq MirageSeen by Mirage: no evidence on record.
No attack traffic recorded by OffSeq Mirage sensors
A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 26 Oct 2026.
What to do
Upgrade to a fixed release listed under Affected software.
Affected software
| Product | Affected | Fixed in |
|---|---|---|
| linux-aws | Affected
| Fixed in
|
AI-suggested
The root cause fix involves populating the ndo_change_mtu() callback in the sun4i_can driver to enforce MTU limits. If you cannot patch yet, avoid setting custom MTU values on CAN interfaces using this driver and restrict local user access to prevent exploitation.
Description
In the Linux kernel, the following vulnerability has been resolved: can: sun4i_can: 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, sun4ican_start_xmit() receives a CAN XL frame which it is not able to correctly handle and will thus misinterpret it as a CAN frame. This can result in a buffer overflow. The driver will consume cf->len as-is with no further checks on this line: dlc = cf->len; Here, cf->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 a couple line below when doing: for (i = 0; i < dlc; i++) writel(cf->data[i], priv->base + (dreg + i * 4)); 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.
References
- nvd.nist.gov/vuln/detail/CVE-2025-39986 (opens in a new tab)
- git.kernel.org/stable/c/063539db42203b29d5aa2adf0cae3d68c646a6b6 (opens in a new tab)
- git.kernel.org/stable/c/2e423e1990f3972cbea779883fef52c2f2acb858 (opens in a new tab)
- git.kernel.org/stable/c/4f382cc887adca8478b9d3e6b81aa6698a95fff4 (opens in a new tab)
- git.kernel.org/stable/c/60463a1c138900494cb3adae41142a11cd8feb3c (opens in a new tab)
- git.kernel.org/stable/c/61da0bd4102c459823fbe6b8b43b01fb6ace4a22 (opens in a new tab)
- git.kernel.org/stable/c/7f7b21026a6febdb749f6f6f950427245aa86cce (opens in a new tab)
- git.kernel.org/stable/c/a61ff7ac93270d20ca426c027d6d01c8ac8e904c (opens in a new tab)
- git.kernel.org/stable/c/de77841652e57afbc46e9e1dbf51ee364fc008e1 (opens in a new tab)
- ubuntu.com/security/CVE-2025-39986 (opens in a new tab)
- cve.org/CVERecord?id=CVE-2025-39986 (opens in a new tab)
- git.kernel.org/linus/61da0bd4102c459823fbe6b8b43b01fb6ace4a22 (opens in a new tab)
- ubuntu.com/security/notices/USN-8033-1 (opens in a new tab)
- ubuntu.com/security/notices/USN-8033-2 (opens in a new tab)
- ubuntu.com/security/notices/USN-8033-3 (opens in a new tab)
- ubuntu.com/security/notices/USN-8034-1 (opens in a new tab)
- ubuntu.com/security/notices/USN-8033-4 (opens in a new tab)
- ubuntu.com/security/notices/USN-8033-5 (opens in a new tab)
- ubuntu.com/security/notices/USN-8034-2 (opens in a new tab)
- ubuntu.com/security/notices/USN-8033-6 (opens in a new tab)
- ubuntu.com/security/notices/USN-8033-7 (opens in a new tab)