CVE-2022-48830

What it actually does

Race condition in isotp_rcv() allows concurrent CAN frame reception to mutate so->rx.len between isotp_rcv_ff() and isotp_rcv_cf(), resulting in skb_put() writing beyond an undersized skb and triggering skb_over_panic.

Why it matters to the business

Systems relying on Linux CAN ISOTP (automotive, industrial control, robotics) may experience kernel panics and denial of service when processing CAN traffic; low real-world exploitability limits broad operational risk despite kernel-level severity.

How an attack unfolds

An attacker with the ability to inject CAN frames sends a mix of First Frame and Consecutive Frame messages in rapid succession; the race allows rx.len to become zero before skb allocation then 4096 afterward, causing the kernel to panic in skb_put during isotp_rcv_cf.

How to fix it

Apply the upstream fix commit 7b53d2204ce79b27a878074a77d64f40ec21dbca or later; rebuild and deploy a patched Linux kernel containing the isotp_rcv spin-lock change; prioritize updates on any system exposing CAN interfaces.

How to confirm the fix worked

Confirm the running kernel contains commit 7b53d2204ce79b27a878074a77d64f40ec21dbca or verify the presence of the spin_lock in net/can/isotp.c around isotp_rcv; test by replaying concurrent FF/CF sequences and ensure no skb_over_panic occurs.

Typical attack path

1. Obtain ability to transmit CAN frames on the target bus
2. Transmit a First Frame to enter isotp_rcv_ff and set initial rx state
3. Immediately follow with Consecutive Frames while another reception path is active
4. Trigger the window where rx.len changes after skb allocation but before skb_put
5. Cause skb_over_panic and kernel crash

How to detect it

Search kernel logs and crash dumps for skb_over_panic, skb_put.cold, isotp_rcv_cf, and isotp_rcv stack traces; correlate with ksoftirqd processes and CAN frame reception activity.

• skb_over_panic net/core/skbuff.c
• isotp_rcv_cf net/can/isotp.c
• isotp_rcv+0xa38/0x1e30 net/can/isotp.c
• CPU:.*PID:.*Comm: ksoftirqd

What your security team should do

• Patch affected Linux kernels to the fixed commit at the earliest maintenance window
• Restrict CAN bus access to trusted endpoints only
• Monitor kernel logs for isotp-related skb panics as an interim detection measure
• Evaluate disabling ISOTP socket support if the protocol is not required