Skip to main content

Linux Kernel CVE-2025-39986

HIGH
2025-10-15 416baaa9-dc9f-4396-8d5f-8c081fb06d67
7.8
CVSS 3.1 · Vendor: 416baaa9-dc9f-4396-8d5f-8c081fb06d67
Share

Severity by source

Vendor (416baaa9-dc9f-4396-8d5f-8c081fb06d67) PRIMARY
7.8 HIGH
AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
vuln.today AI
7.8 HIGH

Local-only path (AV:L) with no user interaction; requires CAP_NET_ADMIN/CAP_NET_RAW so PR:L, and a kernel out-of-bounds write yields high C/I/A.

3.1 AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
4.0 AV:L/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N
SUSE
5.5 MEDIUM
AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H

Primary rating from Vendor (416baaa9-dc9f-4396-8d5f-8c081fb06d67).

CVSS VectorVendor: 416baaa9-dc9f-4396-8d5f-8c081fb06d67

Attack Vector
Local
Attack Complexity
Low
Privileges Required
Low
User Interaction
None
Scope
Unchanged
Confidentiality
High
Integrity
High
Availability
High

Lifecycle Timeline

2
Analysis Generated
Jul 30, 2026 - 08:05 vuln.today
CVE Published
Oct 15, 2025 - 08:15 cve.org
HIGH 7.8

DescriptionCVE.org

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).

  1. 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.

AnalysisAI

Local privilege-enabled buffer overflow in the Linux kernel's sun4i_can CAN controller driver (Allwinner A10/A20 SoCs) allows an attacker holding network-admin capability to write out of bounds by injecting oversized CAN XL frames. Because the driver never populated ndo_change_mtu(), the interface MTU can be raised past CAN_MTU, letting a PF_PACKET raw socket push a frame whose length field is misread as a CAN data length, overflowing a fixed buffer by up to 247 bytes. There is no public exploit identified at time of analysis and EPSS is low (0.22%), but the description includes a detailed, working reproduction path.

Technical ContextAI

The affected component is the sun4i_can Socket CAN driver, which serves the on-chip CAN controller of Allwinner sun4i/sun7i (A10/A20) ARM SoCs. Linux net_device drivers are expected to bound their MTU via net_device_ops->ndo_change_mtu(); when that callback is absent, the core permits arbitrary MTU values. PF_PACKET SOCK_RAW sockets bypass the higher-level CAN framing logic and reach the driver's xmit() directly, with the only gate being that skb->len fits the (now attacker-inflated) MTU. can_dev_dropped_skb() fails to catch the mismatch because skb->protocol is ETH_P_CANXL (accepted without checking device capability) and the length is a valid CAN XL length. sun4ican_start_xmit() then treats a canxl_frame as a classic can_frame, assigning dlc = cf->len (actually the CAN XL flags byte, e.g. 0xff) and looping writel(cf->data[i], ...) for i < dlc, well past the 8-byte classic CAN maximum. This is a classic out-of-bounds write (CWE-787 / CWE-120 class) rooted in missing input validation; the CWE was not assigned in NVD (CWE: N/A).

Affected ProductsAI

The vulnerability affects the sun4i_can driver within the mainline and stable Linux kernel, used on Allwinner A10 (sun4i) and A20 (sun7i) SoCs with an on-chip CAN controller. No explicit affected version range or CPE was supplied in the intelligence; the fix is distributed across eight stable/mainline commits on git.kernel.org (063539db..., 2e423e19..., 4f382cc8..., 60463a1c..., 61da0bd4..., 7f7b2102..., a61ff7ac..., de778416...), indicating backports to multiple maintained stable branches. Exact vulnerable-to-fixed version boundaries should be confirmed against each distribution's kernel changelog, as NVD did not enumerate CPE ranges here.

RemediationAI

Upstream fix available (commit); released patched version not independently confirmed - apply the kernel update that includes the sun4i_can ndo_change_mtu() population, tracked by the git.kernel.org stable commits (e.g. https://git.kernel.org/stable/c/de77841652e57afbc46e9e1dbf51ee364fc008e1 and the seven sibling commits), by upgrading to your distribution's kernel build that incorporates them. Where immediate patching is not possible, compensating controls include blacklisting/unloading the sun4i_can module if CAN is unused (trade-off: disables CAN networking on the device), and restricting CAP_NET_ADMIN and CAP_NET_RAW so untrusted local users cannot change interface MTU or open PF_PACKET raw sockets (trade-off: may break legitimate networking tools and container workloads that rely on these capabilities). These controls address the exploitation path but not the underlying missing MTU check, so patching remains the durable fix.

Vendor StatusVendor

SUSE

Severity: Moderate
Product Status
Container suse/hpc/warewulf4-x86_64/sle-hpc-node:15.6.17.8.134 Image SLES15-SP6 Image SLES15-SP6-BYOS Image SLES15-SP6-BYOS-Azure Image SLES15-SP6-BYOS-EC2 Image SLES15-SP6-BYOS-GCE Image SLES15-SP6-CHOST-BYOS Image SLES15-SP6-CHOST-BYOS-Aliyun Image SLES15-SP6-CHOST-BYOS-Azure Image SLES15-SP6-CHOST-BYOS-EC2 Image SLES15-SP6-CHOST-BYOS-GCE Image SLES15-SP6-CHOST-BYOS-GDC Image SLES15-SP6-CHOST-BYOS-SAP-CCloud Image SLES15-SP6-EC2 Image SLES15-SP6-EC2-ECS-HVM Image SLES15-SP6-GCE Image SLES15-SP6-HPC-BYOS Image SLES15-SP6-HPC-BYOS-Azure Image SLES15-SP6-HPC-BYOS-EC2 Image SLES15-SP6-HPC-BYOS-GCE Image SLES15-SP6-HPC-EC2 Image SLES15-SP6-HPC-GCE Image SLES15-SP6-Hardened-BYOS Image SLES15-SP6-Hardened-BYOS-Azure Image SLES15-SP6-Hardened-BYOS-EC2 Image SLES15-SP6-Hardened-BYOS-GCE Image SLES15-SP6-SAP Image SLES15-SP6-SAP-Azure Image SLES15-SP6-SAP-EC2 Image SLES15-SP6-SAP-GCE Image SLES15-SP6-SAPCAL Image SLES15-SP6-SAPCAL-Azure Image SLES15-SP6-SAPCAL-EC2 Image SLES15-SP6-SAPCAL-GCE Affected
Container suse/sl-micro/6.0/baremetal-os-container:latest Container suse/sl-micro/6.0/toolbox:latest Affected
Container suse/sl-micro/6.0/base-os-container:2.1.3-7.65 Image SLE-Micro Image SLE-Micro-Azure Image SLE-Micro-BYOS Image SLE-Micro-BYOS-Azure Image SLE-Micro-BYOS-EC2 Image SLE-Micro-BYOS-GCE Image SLE-Micro-EC2 Image SLE-Micro-GCE Affected
Container suse/sl-micro/6.0/kvm-os-container:2.1.3-6.88 Affected
Container suse/sl-micro/6.0/rt-os-container:2.1.3-7.105 Affected

Share

CVE-2025-39986 vulnerability details – vuln.today

This site uses cookies essential for authentication and security. No tracking or analytics cookies are used. Privacy Policy