# CVE-2025-39985: can: mcba_usb: populate ndo_change_mtu() to prevent buffer overflow

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

- **Severity:** High 7.8 (`CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H`)
- **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:** Yes
- **Published:** 15 Oct 2025
- **Updated:** 5 Aug 2026
- **Also known as:** AZL-68474, BELL-CVE-2025-39985, DEBIAN-CVE-2025-39985, GHSA-w6wp-c53v-mq5f, ROOT-OS-DEBIAN-11-CVE-2025-39985, ROOT-OS-DEBIAN-12-CVE-2025-39985, ROOT-OS-DEBIAN-13-CVE-2025-39985, ROOT-OS-UBUNTU-2404-CVE-2025-39985, UBUNTU-CVE-2025-39985

## What is CVE-2025-39985?

CVE-2025-39985 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: mcba_usb: 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 mcba_usb 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, mcba_usb_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 these lines:

	usb_msg.dlc = cf->len;

	memcpy(usb_msg.data, cf->data, usb_msg.dlc);

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. By
fixing the root cause, this prevents the buffer overflow.

## Which versions are affected by CVE-2025-39985?


## How do I fix CVE-2025-39985?

Apply the vendor's patch.

## Is CVE-2025-39985 being exploited?

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

## Fix prompt for AI coding agents

```text
Check this codebase for CVE-2025-39985 and fix it if it is affected.

What it is: CVE-2025-39985 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.
Exploitation: There is no known exploitation of CVE-2025-39985 in the wild and no public exploit code.

Affected product: Linux. No package-level version data is available, so check the vendor advisory linked from the reference page.

Task:
1. Search the dependency manifests and lockfiles (for example package.json, package-lock.json, requirements.txt, poetry.lock, uv.lock, pom.xml, build.gradle, go.mod, Cargo.lock, Gemfile.lock) and any Dockerfiles for the affected packages, including transitive dependencies.
2. If an affected version is in use, upgrade it to the fixed version for its release line with the project's package manager, so the lockfile is regenerated. Prefer the smallest upgrade that fixes it.
3. If there is no fix, or the upgrade would break the build, do not guess: explain the risk and the safest workaround instead.
4. Run the tests and summarise what changed and why.
5. If nothing in the project is affected, say so and change nothing.

Reference: https://insights.sbomify.com/CVE-2025-39985/ (Markdown: https://insights.sbomify.com/CVE-2025-39985/index.md)
```

## Sources

- CVE record: https://www.cve.org/CVERecord?id=CVE-2025-39985
- NVD: https://nvd.nist.gov/vuln/detail/CVE-2025-39985
- OSV: https://osv.dev/vulnerability/CVE-2025-39985

---
From sbomify Insights: https://insights.sbomify.com/CVE-2025-39985/
Summaries are generated and may contain mistakes; the official description above is the record.