CVE-2025-39988: can: etas_es58x: populate ndo_change_mtu() to prevent buffer overflow
In the Linux kernel, the following vulnerability has been resolved:
can: etas_es58x: 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 etas_es58x 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, es58x_start_xmit() receives a CAN XL frame which it is not
able to correctly handle and will thus misinterpret it as a CAN(FD)
frame.
This can result in a buffer overflow. For example, using the es581.4
variant, the frame will be dispatched to es581_4_tx_can_msg(), go
through the last check at the beginning of this function:
if (can_is_canfd_skb(skb))
return -EMSGSIZE;
and reach this line:
memcpy(tx_can_msg->data, cf->data, 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!
Populate net_device_ops->ndo_change_mtu() to ensure that the
interface's MTU can not be set to anything bigger than CAN_MTU or
CANFD_MTU (depending on the device capabilities). By fixing the root
cause, this prevents the buffer overflow.
Security readout for executives and security teams
Plain-English summary
A local attacker with limited privileges could abuse an ETAS ES58x CAN interface to overflow a Linux kernel buffer. Successful exploitation could crash the system or compromise confidentiality, integrity, and availability. Exposure is limited to systems using the affected driver and permitting the required network-interface and raw-socket operations.
Executive priority
Treat this as high priority for operational, automotive, laboratory, or embedded Linux systems using ETAS ES58x CAN interfaces. Patch promptly where potentially untrusted local workloads hold relevant capabilities. Systems without the driver or compatible interface are unlikely to be directly exposed based on the supplied evidence.
Technical view
The etas_es58x driver lacked an MTU-change handler. An invalidly large MTU allowed a CAN XL packet to reach transmission code that treated it as CAN or CAN FD. A length value was then misread from another frame field, causing an out-of-bounds copy. Stable kernel fixes restrict MTU values to device-supported CAN limits.
Likely exposure
Prioritize Linux systems using the etas_es58x CAN driver, particularly where non-administrative services or users can change the CAN interface MTU and create PF_PACKET raw sockets. The bundle identifies affected releases or branch boundaries from Linux 5.13 through 6.17, but does not provide enough range structure to determine every affected build precisely.
Exploitation context
The CVSS assessment is 7.8 with local access, low complexity, low privileges, and no user interaction. Exploitation requires access to an affected CAN interface plus permissions for MTU changes and raw packet sockets. The bundle marks this CVE as not present in KEV and provides no evidence of active exploitation.
Researcher notes
The root issue is missing ndo_change_mtu enforcement, allowing PF_PACKET validation to rely on an attacker-influenced MTU. The driver then accepts a CAN XL packet despite lacking that capability and interprets it as CAN(FD). The supplied commits address the root cause by binding permitted MTU values to device capabilities. Exact affected-version ranges remain ambiguous in the bundled data.
Mitigation direction
Upgrade to a vendor kernel containing the applicable stable fix or backport.
Prioritize systems where the etas_es58x driver and compatible CAN interface are actively used.
Restrict untrusted access to network-administration and raw-socket capabilities until patched.
Check distribution or appliance vendor guidance for exact fixed package versions.
Validation and detection
Inventory systems for the etas_es58x driver and attached ETAS ES58x interfaces.
Record kernel and vendor package versions on systems where the driver is present.
Confirm vendor changelogs reference CVE-2025-39988 or an applicable stable commit.
Verify patched interfaces reject MTUs above their supported CAN or CAN FD limit.
Review capability assignments granting network administration or raw-socket access.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cve · low confidence lookup
CVE-2025-39988 mapping review
Open the CVE-to-ATT&CK bridge for reviewed, inferred, or future official mappings tied to this CVE.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.
1CVSS vectors
3Timeline events
0ADP providers
7Source links
CVSS vector scores
1 official score
We collect every scored CVSS vector available in the official CNA and ADP containers. When more than one version is present, the table keeps the source vectors side by side instead of collapsing them into the highest score.