CVE-2021-47459

What it actually does

Race condition in j1939_netdev_start allows concurrent kref_get on rx_kref after it has reached zero via kref_put, triggering use-after-free and refcount warning in the CAN J1939 netdev handling path.

Why it matters to the business

Systems using J1939 CAN sockets may experience kernel crashes, memory corruption, or local privilege escalation, with high urgency for fleets or embedded devices relying on automotive networking stacks.

How an attack unfolds

An attacker with local access binds multiple J1939 sockets to the same netdev in quick succession, forcing one CPU to drop the reference while another increments it without lock protection, leading to the refcount saturation and subsequent use-after-free when the structure is freed.

How to fix it

Apply the upstream fix that serializes rx_kref operations under j1939_netdev_lock; for Ubuntu 16.04 LTS packages the corrected libndp versions are 1.4-2ubuntu0.16.04.1 (noting the kernel-side J1939 change must be backported or the kernel updated).

How to confirm the fix worked

Rebuild or boot a kernel containing the lock around kref operations, then attempt concurrent J1939 socket binds while monitoring for absence of refcount_warn_saturate calls in dmesg.

Typical attack path

1. Obtain local shell or code execution on target Linux system with J1939 CAN support enabled
2. Create and bind multiple AF_CAN sockets using J1939 protocol to the same network device in rapid succession
3. Trigger the race between j1939_netdev_start and j1939_netdev_stop paths
4. Observe refcount warning followed by potential kernel panic or exploitable memory corruption

How to detect it

Search kernel logs and dmesg for repeated 'refcount_warn_saturate' or 'addition on 0' messages originating from j1939_netdev_start; inspect for unusual sequences of socket bind calls on CAN devices.

• refcount_warn_saturate+0x169/0x1e0
• addition on 0; use-after-free
• j1939_netdev_start
• j1939_sk_bind

What your security team should do

• Prioritize kernel updates on any system exposing CAN J1939 interfaces within the next patch cycle
• Disable J1939 protocol module if automotive CAN is not required
• Add monitoring for refcount warnings in kernel logs as an interim detection measure