| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <2025041732-CVE-2020-36789-bb60@gregkh> Date: Thu, 17 Apr 2025 20:01:33 +0200 From: Greg Kroah-Hartman <gregkh@...uxfoundation.org> To: linux-cve-announce@...r.kernel.org Cc: Greg Kroah-Hartman <gregkh@...nel.org> Subject: CVE-2020-36789: can: dev: can_get_echo_skb(): prevent call to kfree_skb() in hard IRQ context From: Greg Kroah-Hartman <gregkh@...nel.org> Description =========== In the Linux kernel, the following vulnerability has been resolved: can: dev: can_get_echo_skb(): prevent call to kfree_skb() in hard IRQ context If a driver calls can_get_echo_skb() during a hardware IRQ (which is often, but not always, the case), the 'WARN_ON(in_irq)' in net/core/skbuff.c#skb_release_head_state() might be triggered, under network congestion circumstances, together with the potential risk of a NULL pointer dereference. The root cause of this issue is the call to kfree_skb() instead of dev_kfree_skb_irq() in net/core/dev.c#enqueue_to_backlog(). This patch prevents the skb to be freed within the call to netif_rx() by incrementing its reference count with skb_get(). The skb is finally freed by one of the in-irq-context safe functions: dev_consume_skb_any() or dev_kfree_skb_any(). The "any" version is used because some drivers might call can_get_echo_skb() in a normal context. The reason for this issue to occur is that initially, in the core network stack, loopback skb were not supposed to be received in hardware IRQ context. The CAN stack is an exeption. This bug was previously reported back in 2017 in [1] but the proposed patch never got accepted. While [1] directly modifies net/core/dev.c, we try to propose here a smoother modification local to CAN network stack (the assumption behind is that only CAN devices are affected by this issue). [1] http://lore.kernel.org/r/57a3ffb6-3309-3ad5-5a34-e93c3fe3614d@cetitec.com The Linux kernel CVE team has assigned CVE-2020-36789 to this issue. Affected and fixed versions =========================== Issue introduced in 2.6.31 with commit 39549eef3587f1c1e8c65c88a2400d10fd30ea17 and fixed in 4.4.244 with commit 248b71ce92d4f3a574b2537f9838f48e892618f4 Issue introduced in 2.6.31 with commit 39549eef3587f1c1e8c65c88a2400d10fd30ea17 and fixed in 4.9.244 with commit 451187b20431924d13fcfecc500d7cd2d9951bac Issue introduced in 2.6.31 with commit 39549eef3587f1c1e8c65c88a2400d10fd30ea17 and fixed in 4.14.207 with commit 3a922a85701939624484e7f2fd07d32beed00d25 Issue introduced in 2.6.31 with commit 39549eef3587f1c1e8c65c88a2400d10fd30ea17 and fixed in 4.19.158 with commit 7e4cf2ec0ca236c3e5f904239cec6efe1f3baf22 Issue introduced in 2.6.31 with commit 39549eef3587f1c1e8c65c88a2400d10fd30ea17 and fixed in 5.4.78 with commit ab46748bf98864f9c3f5559060bf8caf9df2b41e Issue introduced in 2.6.31 with commit 39549eef3587f1c1e8c65c88a2400d10fd30ea17 and fixed in 5.9.9 with commit 87530b557affe01c764de32dbeb58cdf47234574 Issue introduced in 2.6.31 with commit 39549eef3587f1c1e8c65c88a2400d10fd30ea17 and fixed in 5.10 with commit 2283f79b22684d2812e5c76fc2280aae00390365 Please see https://www.kernel.org for a full list of currently supported kernel versions by the kernel community. Unaffected versions might change over time as fixes are backported to older supported kernel versions. The official CVE entry at https://cve.org/CVERecord/?id=CVE-2020-36789 will be updated if fixes are backported, please check that for the most up to date information about this issue. Affected files ============== The file(s) affected by this issue are: drivers/net/can/dev.c Mitigation ========== The Linux kernel CVE team recommends that you update to the latest stable kernel version for this, and many other bugfixes. Individual changes are never tested alone, but rather are part of a larger kernel release. Cherry-picking individual commits is not recommended or supported by the Linux kernel community at all. If however, updating to the latest release is impossible, the individual changes to resolve this issue can be found at these commits: https://git.kernel.org/stable/c/248b71ce92d4f3a574b2537f9838f48e892618f4 https://git.kernel.org/stable/c/451187b20431924d13fcfecc500d7cd2d9951bac https://git.kernel.org/stable/c/3a922a85701939624484e7f2fd07d32beed00d25 https://git.kernel.org/stable/c/7e4cf2ec0ca236c3e5f904239cec6efe1f3baf22 https://git.kernel.org/stable/c/ab46748bf98864f9c3f5559060bf8caf9df2b41e https://git.kernel.org/stable/c/87530b557affe01c764de32dbeb58cdf47234574 https://git.kernel.org/stable/c/2283f79b22684d2812e5c76fc2280aae00390365
Powered by blists - more mailing lists