CVE-2022-48719
net, neigh: Do not trigger immediate probes on NUD_FAILED from neigh_managed_work
Severity Score
Exploit Likelihood
Affected Versions
Public Exploits
0Exploited in Wild
-Decision
Descriptions
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. Para el caso de NTF_MANAGED, este aplazamiento es aceptable dado que esto solo ocurre en el estado de falla real y el estado normal/esperado es NUD_VALID con la entrada ya presente. La solución agrega un parámetro a __neigh_event_send() para comunicar si se permite o no la sonda inmediata. Los sitios de llamadas existentes de neigh_event_send() están predeterminados tal cual para la investigación inmediata. Sin embargo, neigh_managed_work() lo desactiva mediante el uso de neigh_event_send_probe(). [0] __dump_stack lib/dump_stack.c:88 [en línea] dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106 print_deadlock_bug kernel/locking/lockdep.c:2956 [en línea] check_deadlock kernel/locking/lockdep.c :2999 [en línea] validar_chain kernel/locking/lockdep.c:3788 [en línea] __lock_acquire.cold+0x149/0x3ab kernel/locking/lockdep.c:5027 lock_acquire kernel/locking/lockdep.c:5639 [en línea] lock_acquire+0x1ab /0x510 kernel/locking/lockdep.c:5604 __raw_write_lock_bh include/linux/rwlock_api_smp.h:202 [en línea] _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 [en línea] __ip6_finish_output+0x61e/0xe90 net/ipv6/ip6_output.c:170 poner+0x32/0x200 neto/ ipv6/ip6_output.c:201 NF_HOOK_COND include/linux/netfilter.h:296 [en línea] ip6_output+0x1e4/0x530 net/ipv6/ip6_output.c:224 dst_output include/net/dst.h:451 [en línea] NF_HOOK include/ linux/netfilter.h:307 [en línea] 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 [en línea] neigh_managed_work+0x162/0x250 net/ core/neighbour.c:1574 Process_one_work+0x9ac/0x1650 kernel/workqueue.c:2307 trabajador_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
CVSS Scores
SSVC
- Decision:Track
Timeline
- 2024-06-20 CVE Reserved
- 2024-06-20 CVE Published
- 2024-06-21 EPSS Updated
- 2024-11-04 CVE Updated
- ---------- Exploited in Wild
- ---------- KEV Due Date
- ---------- First Exploit
CWE
CAPEC
References (3)
URL | Tag | Source |
---|---|---|
https://git.kernel.org/stable/c/7482e3841d520a368426ac196720601687e2dc47 | Vuln. Introduced |
URL | Date | SRC |
---|
URL | Date | SRC |
---|---|---|
https://git.kernel.org/stable/c/203a35ebb49cdce377416b0690215d3ce090d364 | 2022-02-08 | |
https://git.kernel.org/stable/c/4a81f6da9cb2d1ef911131a6fd8bd15cb61fc772 | 2022-02-03 |
URL | Date | SRC |
---|
Affected Vendors, Products, and Versions
Vendor | Product | Version | Other | Status | ||||||
---|---|---|---|---|---|---|---|---|---|---|
Vendor | Product | Version | Other | Status | <-- --> | Vendor | Product | Version | Other | Status |
Linux Search vendor "Linux" | Linux Kernel Search vendor "Linux" for product "Linux Kernel" | >= 5.16 < 5.16.8 Search vendor "Linux" for product "Linux Kernel" and version " >= 5.16 < 5.16.8" | en |
Affected
| ||||||
Linux Search vendor "Linux" | Linux Kernel Search vendor "Linux" for product "Linux Kernel" | >= 5.16 < 5.17 Search vendor "Linux" for product "Linux Kernel" and version " >= 5.16 < 5.17" | en |
Affected
|