CVE-2021-47519

What it actually does

Local memory leak in m_can_read_fifo() where an skb allocated via alloc_can_skb() is not released on failure of the subsequent m_can_fifo_read() call, causing the error path to return without invoking m_can_receive_skb().

Why it matters to the business

Repeated triggering by a local process can exhaust kernel memory on affected Linux systems, leading to degraded performance or denial of service for CAN bus operations without remote attack surface.

How an attack unfolds

An attacker with local access crafts conditions that cause the second m_can_fifo_read() to fail after skb allocation, repeatedly leaking memory until the system becomes unstable.

How to fix it

Apply the upstream kernel patch that adds an skb destruction goto label in the error path of m_can_read_fifo(); rebuild and deploy an updated kernel containing this fix.

How to confirm the fix worked

Inspect the m_can.c source for the presence of the skb free operation before the out_fail return; compile with -fanalyzer or run targeted CAN receive error injection tests to confirm absence of the leak.

Typical attack path

1. Obtain local code execution or shell access on a Linux system using the m_can CAN controller driver.
2. Trigger repeated CAN receive operations that force the error branch in m_can_read_fifo().
3. Observe progressive kernel memory consumption until availability impact occurs.

How to detect it

Review kernel memory usage trends and slab allocator statistics around CAN driver activity; correlate with local process logs that interact with /dev/can or m_can interfaces for unusual error paths.

What your security team should do

• Prioritize kernel updates on systems exposing the m_can driver.
• Monitor for local privilege escalation attempts that could leverage memory pressure.
• Review CAN bus usage in embedded or automotive deployments for exposure.