CVE-2025-39873

What it actually does

Use-after-free of a transmitted socket buffer (SKB) in xcan_write_frame() because can_put_echo_skb() takes ownership and may free the SKB while the caller still accesses it under tx_lock.

Why it matters to the business

Potential kernel crashes, denial of service, or local privilege escalation on systems using the Xilinx CAN driver; high downstream Linux kernel prevalence increases exposure for embedded, automotive, and industrial deployments even though EPSS remains low and no KEV listing exists.

How an attack unfolds

An attacker with local access or the ability to trigger CAN frame transmission on an affected Xilinx CAN interface causes xcan_write_frame() to access the SKB after can_put_echo_skb() has released it, leading to a use-after-free that threat actors such as VMSCAPE have been observed targeting in similar Linux kernel privilege-escalation scenarios.

How to fix it

Update the Linux kernel to commit e202ffd9e54538ef67ec301ebd6d9da4823466c9 or later; for Debian 11-14 samba packages apply 2:4.1.9+dfsg-1 or newer; verify the xilinx_can driver is no longer present or is the patched version after reboot.

How to confirm the fix worked

Confirm the running kernel contains commit e202ffd9e54538ef67ec301ebd6d9da4823466c9 via uname or git describe; attempt CAN frame transmission under load while monitoring for use-after-free warnings or crashes in dmesg; re-test after applying the listed fixed package versions.

Typical attack path

1. Obtain local execution or CAN interface access on a vulnerable Linux kernel with the xilinx_can driver loaded.
2. Trigger transmission of a CAN frame that enters xcan_write_frame().
3. Exploit the window between can_put_echo_skb() and subsequent SKB access to perform use-after-free operations.
4. Leverage the resulting memory corruption for denial of service or privilege escalation.

How to detect it

Review kernel logs (dmesg, /var/log/kern.log) for oops, warnings, or stack traces referencing xcan_write_frame, can_put_echo_skb, or xilinx_can around the time of suspected activity; correlate with process creation or CAN socket usage by untrusted users or containers.

What your security team should do

• Prioritize kernel upgrade to the listed fixed commit or Debian package versions within the next patch cycle given the 399-day publication window and known similar exploits by VMSCAPE.
• Restrict local CAN interface access and unprivileged container workloads until patches are deployed.
• Monitor EPSS trend (stable at ~0.0016) and re-evaluate if new exploit maturity indicators appear.