CVE-2020-36789

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> can: dev: can_get_echo_skb(): prevent call to kfree_skb() in hard IRQ context<br /> <br /> If a driver calls can_get_echo_skb() during a hardware IRQ (which is often, but<br /> not always, the case), the &amp;#39;WARN_ON(in_irq)&amp;#39; in<br /> net/core/skbuff.c#skb_release_head_state() might be triggered, under network<br /> congestion circumstances, together with the potential risk of a NULL pointer<br /> dereference.<br /> <br /> The root cause of this issue is the call to kfree_skb() instead of<br /> dev_kfree_skb_irq() in net/core/dev.c#enqueue_to_backlog().<br /> <br /> This patch prevents the skb to be freed within the call to netif_rx() by<br /> incrementing its reference count with skb_get(). The skb is finally freed by<br /> one of the in-irq-context safe functions: dev_consume_skb_any() or<br /> dev_kfree_skb_any(). The "any" version is used because some drivers might call<br /> can_get_echo_skb() in a normal context.<br /> <br /> The reason for this issue to occur is that initially, in the core network<br /> stack, loopback skb were not supposed to be received in hardware IRQ context.<br /> The CAN stack is an exeption.<br /> <br /> This bug was previously reported back in 2017 in [1] but the proposed patch<br /> never got accepted.<br /> <br /> While [1] directly modifies net/core/dev.c, we try to propose here a<br /> smoother modification local to CAN network stack (the assumption<br /> behind is that only CAN devices are affected by this issue).<br /> <br /> [1] http://lore.kernel.org/r/57a3ffb6-3309-3ad5-5a34-e93c3fe3614d@cetitec.com