Katalog CVE

CVE-2024-27010

ŚrednieCVSS 5.5
Opublikowano: Zaktualizowano: Przetłumaczono: NVD NIST

Prawdopodobieństwo exploitacji (EPSS)

Niskie ryzyko
0.18%

Percentyl 7 - wyżej niż 7% wszystkich znanych CVE

Streszczenie

W jądrze Linux występuje zakleszczenie (deadlock) w podsystemie net/sched. Gdy akcja mirred jest używana na klasowym qdisc egress i pakiet jest lustrzany lub przekierowywany do samego siebie, dochodzi do ponownego założenia tego samego zamka qdisc na tym samym CPU. Problem rozwiązano dodając pole właściciela (CPU id) do struktury Qdisc i odrzucanie pakietu przy ponownym wejściu z tego samego CPU.

Ocena ryzyka

Zakleszczenie może doprowadzić do zawieszenia stosu sieciowego jądra, co skutkuje niedostępnością sieci na dotkniętym systemie. Wymaga to jednak konkretnej konfiguracji reguł tc z akcją mirred przekierowującą ruch do tego samego interfejsu.

Rekomendacja

Zaktualizuj jądro Linux do wersji zawierającej poprawkę dla CVE-2024-27010. Do czasu aktualizacji unikaj konfiguracji tc, w których akcja mirred przekierowuje lub lustrzy pakiety z powrotem do tego samego interfejsu.

Inne podatności w Linux kernel

Zobacz wszystkie
Oryginalny opis (angielski, źródło NVD)

In the Linux kernel, the following vulnerability has been resolved: net/sched: Fix mirred deadlock on device recursion When the mirred action is used on a classful egress qdisc and a packet is mirrored or redirected to self we hit a qdisc lock deadlock. See trace below. [..... other info removed for brevity....] [ 82.890906] [ 82.890906] ============================================ [ 82.890906] WARNING: possible recursive locking detected [ 82.890906] 6.8.0-05205-g77fadd89fe2d-dirty #213 Tainted: G W [ 82.890906] -------------------------------------------- [ 82.890906] ping/418 is trying to acquire lock: [ 82.890906] ffff888006994110 (&sch->q.lock){+.-.}-{3:3}, at: __dev_queue_xmit+0x1778/0x3550 [ 82.890906] [ 82.890906] but task is already holding lock: [ 82.890906] ffff888006994110 (&sch->q.lock){+.-.}-{3:3}, at: __dev_queue_xmit+0x1778/0x3550 [ 82.890906] [ 82.890906] other info that might help us debug this: [ 82.890906] Possible unsafe locking scenario: [ 82.890906] [ 82.890906] CPU0 [ 82.890906] ---- [ 82.890906] lock(&sch->q.lock); [ 82.890906] lock(&sch->q.lock); [ 82.890906] [ 82.890906] *** DEADLOCK *** [ 82.890906] [..... other info removed for brevity....] Example setup (eth0->eth0) to recreate tc qdisc add dev eth0 root handle 1: htb default 30 tc filter add dev eth0 handle 1: protocol ip prio 2 matchall \ action mirred egress redirect dev eth0 Another example(eth0->eth1->eth0) to recreate tc qdisc add dev eth0 root handle 1: htb default 30 tc filter add dev eth0 handle 1: protocol ip prio 2 matchall \ action mirred egress redirect dev eth1 tc qdisc add dev eth1 root handle 1: htb default 30 tc filter add dev eth1 handle 1: protocol ip prio 2 matchall \ action mirred egress redirect dev eth0 We fix this by adding an owner field (CPU id) to struct Qdisc set after root qdisc is entered. When the softirq enters it a second time, if the qdisc owner is the same CPU, the packet is dropped to break the loop.

Dane podatności pochodzą z NVD (NIST) · CISA KEV · EPSS