CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2022-48723 – spi: uniphier: fix reference count leak in uniphier_spi_probe()
https://notcve.org/view.php?id=CVE-2022-48723
In the Linux kernel, the following vulnerability has been resolved: spi: uniphier: fix reference count leak in uniphier_spi_probe() The issue happens in several error paths in uniphier_spi_probe(). When either dma_get_slave_caps() or devm_spi_register_master() returns an error code, the function forgets to decrease the refcount of both `dma_rx` and `dma_tx` objects, which may lead to refcount leaks. Fix it by decrementing the reference count of specific objects in those error paths. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: spi: uniphier: corrige la fuga del recuento de referencias en uniphier_spi_probe() El problema ocurre en varias rutas de error en uniphier_spi_probe(). Cuando dma_get_slave_caps() o devm_spi_register_master() devuelven un código de error, la función se olvida de disminuir el recuento de los objetos `dma_rx` y `dma_tx`, lo que puede provocar fugas de recuento. Corríjalo disminuyendo el recuento de referencias de objetos específicos en esas rutas de error. • https://git.kernel.org/stable/c/28d1dddc59f6b7fc085093e7c1e978b33f0caf4c https://git.kernel.org/stable/c/e895e067d73e154b1ebc84a124e00831e311d9b0 https://git.kernel.org/stable/c/dd00b4f8f768d81c3788a8ac88fdb3d745e55ea3 https://git.kernel.org/stable/c/447c3d4046d7b54052d07d8b27e15e6edea5662c https://git.kernel.org/stable/c/37c2c83ca4f1ef4b6908181ac98e18360af89b42 •
CVSS: -EPSS: 0%CPEs: 7EXPL: 0CVE-2022-48722 – net: ieee802154: ca8210: Stop leaking skb's
https://notcve.org/view.php?id=CVE-2022-48722
In the Linux kernel, the following vulnerability has been resolved: net: ieee802154: ca8210: Stop leaking skb's Upon error the ieee802154_xmit_complete() helper is not called. Only ieee802154_wake_queue() is called manually. We then leak the skb structure. Free the skb structure upon error before returning. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: net: ieee802154: ca8210: Detener la fuga de skb. En caso de error, no se llama al asistente ieee802154_xmit_complete(). • https://git.kernel.org/stable/c/ded845a781a578dfb0b5b2c138e5a067aa3b1242 https://git.kernel.org/stable/c/a1c277b0ed2a13e7de923b5f03bc23586eceb851 https://git.kernel.org/stable/c/d6a44feb2f28d71a7e725f72d09c97c81561cd9a https://git.kernel.org/stable/c/6f38d3a6ec11c2733b1c641a46a2a2ecec57be08 https://git.kernel.org/stable/c/78b3f20c17cbcb7645bfa63f2ca0e11b53c09d56 https://git.kernel.org/stable/c/94cd597e20ed4acedb8f15f029d92998b011cb1a https://git.kernel.org/stable/c/21feb6df3967541931242c427fe0958276af81cc https://git.kernel.org/stable/c/621b24b09eb61c63f262da0c9c5f0e933 •
CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2022-48721 – net/smc: Forward wakeup to smc socket waitqueue after fallback
https://notcve.org/view.php?id=CVE-2022-48721
In the Linux kernel, the following vulnerability has been resolved: net/smc: Forward wakeup to smc socket waitqueue after fallback When we replace TCP with SMC and a fallback occurs, there may be some socket waitqueue entries remaining in smc socket->wq, such as eppoll_entries inserted by userspace applications. After the fallback, data flows over TCP/IP and only clcsocket->wq will be woken up. Applications can't be notified by the entries which were inserted in smc socket->wq before fallback. So we need a mechanism to wake up smc socket->wq at the same time if some entries remaining in it. The current workaround is to transfer the entries from smc socket->wq to clcsock->wq during the fallback. But this may cause a crash like this: general protection fault, probably for non-canonical address 0xdead000000000100: 0000 [#1] PREEMPT SMP PTI CPU: 3 PID: 0 Comm: swapper/3 Kdump: loaded Tainted: G E 5.16.0+ #107 RIP: 0010:__wake_up_common+0x65/0x170 Call Trace: <IRQ> __wake_up_common_lock+0x7a/0xc0 sock_def_readable+0x3c/0x70 tcp_data_queue+0x4a7/0xc40 tcp_rcv_established+0x32f/0x660 ? sk_filter_trim_cap+0xcb/0x2e0 tcp_v4_do_rcv+0x10b/0x260 tcp_v4_rcv+0xd2a/0xde0 ip_protocol_deliver_rcu+0x3b/0x1d0 ip_local_deliver_finish+0x54/0x60 ip_local_deliver+0x6a/0x110 ? • https://git.kernel.org/stable/c/fb92e025baa73e99250b79ab64f4e088d2888993 https://git.kernel.org/stable/c/2153bd1e3d3dbf6a3403572084ef6ed31c53c5f0 https://git.kernel.org/stable/c/d6e981ec9491be5ec46d838b1151e7edefe607f5 https://git.kernel.org/stable/c/ff6eeb627898c179aac421af5d6515d3f50b84df https://git.kernel.org/stable/c/0ef6049f664941bc0f75828b3a61877635048b27 https://git.kernel.org/stable/c/504078fbe9dd570d685361b57784a6050bc40aaa https://git.kernel.org/stable/c/341adeec9adad0874f29a0a1af35638207352a39 •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2022-48720 – net: macsec: Fix offload support for NETDEV_UNREGISTER event
https://notcve.org/view.php?id=CVE-2022-48720
In the Linux kernel, the following vulnerability has been resolved: net: macsec: Fix offload support for NETDEV_UNREGISTER event Current macsec netdev notify handler handles NETDEV_UNREGISTER event by releasing relevant SW resources only, this causes resources leak in case of macsec HW offload, as the underlay driver was not notified to clean it's macsec offload resources. Fix by calling the underlay driver to clean it's relevant resources by moving offload handling from macsec_dellink() to macsec_common_dellink() when handling NETDEV_UNREGISTER event. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: macsec: se corrigió el soporte de descarga para el evento NETDEV_UNREGISTER. El controlador de notificación netdev de macsec actual maneja el evento NETDEV_UNREGISTER liberando solo recursos SW relevantes, lo que provoca una pérdida de recursos en caso de descarga de HW de macsec, ya que No se notificó al controlador subyacente que limpiara sus recursos de descarga de macsec. Para solucionarlo, llame al controlador subyacente para limpiar sus recursos relevantes moviendo el manejo de descarga de macsec_dellink() a macsec_common_dellink() cuando se maneja el evento NETDEV_UNREGISTER. • https://git.kernel.org/stable/c/3cf3227a21d1fb020fe26128e60321bd2151e922 https://git.kernel.org/stable/c/2e7f5b6ee1a7a2c628253a95b0a95b582901ef1b https://git.kernel.org/stable/c/e7a0b3a0806dae3cc81931f0e83055ca2ac6f455 https://git.kernel.org/stable/c/8299be160aad8548071d080518712dec0df92bd5 https://git.kernel.org/stable/c/9cef24c8b76c1f6effe499d2f131807c90f7ce9a •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2022-48719 – net, neigh: Do not trigger immediate probes on NUD_FAILED from neigh_managed_work
https://notcve.org/view.php?id=CVE-2022-48719
In the Linux kernel, the following vulnerability has been resolved: net, neigh: Do not trigger immediate probes on NUD_FAILED from neigh_managed_work syzkaller was able to trigger a deadlock for NTF_MANAGED entries [0]: kworker/0:16/14617 is trying to acquire lock: ffffffff8d4dd370 (&tbl->lock){++-.}-{2:2}, at: ___neigh_create+0x9e1/0x2990 net/core/neighbour.c:652 [...] but task is already holding lock: ffffffff8d4dd370 (&tbl->lock){++-.}-{2:2}, at: neigh_managed_work+0x35/0x250 net/core/neighbour.c:1572 The neighbor entry turned to NUD_FAILED state, where __neigh_event_send() triggered an immediate probe as per commit cd28ca0a3dd1 ("neigh: reduce arp latency") via neigh_probe() given table lock was held. One option to fix this situation is to defer the neigh_probe() back to the neigh_timer_handler() similarly as pre cd28ca0a3dd1. For the case of NTF_MANAGED, this deferral is acceptable given this only happens on actual failure state and regular / expected state is NUD_VALID with the entry already present. The fix adds a parameter to __neigh_event_send() in order to communicate whether immediate probe is allowed or disallowed. Existing call-sites of neigh_event_send() default as-is to immediate probe. However, the neigh_managed_work() disables it via use of neigh_event_send_probe(). [0] <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106 print_deadlock_bug kernel/locking/lockdep.c:2956 [inline] check_deadlock kernel/locking/lockdep.c:2999 [inline] validate_chain kernel/locking/lockdep.c:3788 [inline] __lock_acquire.cold+0x149/0x3ab kernel/locking/lockdep.c:5027 lock_acquire kernel/locking/lockdep.c:5639 [inline] lock_acquire+0x1ab/0x510 kernel/locking/lockdep.c:5604 __raw_write_lock_bh include/linux/rwlock_api_smp.h:202 [inline] _raw_write_lock_bh+0x2f/0x40 kernel/locking/spinlock.c:334 ___neigh_create+0x9e1/0x2990 net/core/neighbour.c:652 ip6_finish_output2+0x1070/0x14f0 net/ipv6/ip6_output.c:123 __ip6_finish_output net/ipv6/ip6_output.c:191 [inline] __ip6_finish_output+0x61e/0xe90 net/ipv6/ip6_output.c:170 ip6_finish_output+0x32/0x200 net/ipv6/ip6_output.c:201 NF_HOOK_COND include/linux/netfilter.h:296 [inline] ip6_output+0x1e4/0x530 net/ipv6/ip6_output.c:224 dst_output include/net/dst.h:451 [inline] NF_HOOK include/linux/netfilter.h:307 [inline] ndisc_send_skb+0xa99/0x17f0 net/ipv6/ndisc.c:508 ndisc_send_ns+0x3a9/0x840 net/ipv6/ndisc.c:650 ndisc_solicit+0x2cd/0x4f0 net/ipv6/ndisc.c:742 neigh_probe+0xc2/0x110 net/core/neighbour.c:1040 __neigh_event_send+0x37d/0x1570 net/core/neighbour.c:1201 neigh_event_send include/net/neighbour.h:470 [inline] neigh_managed_work+0x162/0x250 net/core/neighbour.c:1574 process_one_work+0x9ac/0x1650 kernel/workqueue.c:2307 worker_thread+0x657/0x1110 kernel/workqueue.c:2454 kthread+0x2e9/0x3a0 kernel/kthread.c:377 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:295 </TASK> En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net, neigh: no activar sondas inmediatas en NUD_FAILED desde neigh_managed_work syzkaller pudo activar un punto muerto para las entradas NTF_MANAGED [0]: kworker/0:16/14617 está intentando adquirir bloqueo: ffffffff8d4dd370 (&tbl->lock){++-.}-{2:2}, en: ___neigh_create+0x9e1/0x2990 net/core/neighbour.c:652 [...] pero la tarea ya mantiene el bloqueo: ffffffff8d4dd370 (&tbl->lock){++-.}-{2:2}, en: neigh_managed_work+0x35/0x250 net/core/neighbour.c:1572 La entrada del vecino pasó al estado NUD_FAILED, donde __neigh_event_send() desencadenó una Sondeo inmediato según el commit cd28ca0a3dd1 ("relincho: reducir la latencia de arp") a través de neigh_probe() dado que se mantuvo el bloqueo de la tabla. Una opción para solucionar esta situación es posponer neigh_probe() nuevamente a neigh_timer_handler() de manera similar a como se hacía antes de cd28ca0a3dd1. • https://git.kernel.org/stable/c/7482e3841d520a368426ac196720601687e2dc47 https://git.kernel.org/stable/c/203a35ebb49cdce377416b0690215d3ce090d364 https://git.kernel.org/stable/c/4a81f6da9cb2d1ef911131a6fd8bd15cb61fc772 •