Katalog CVE

CVE-2026-80739

Niskie ryzyko· EPSS 10%
Opublikowano: Przetłumaczono: NVD NIST

Prawdopodobieństwo exploitacji (EPSS)

Niskie ryzyko
0.20%

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

Streszczenie

W jądrze Linux w sterowniku mlx5e (dla kart sieciowych Mellanox/NVIDIA) wykryto podatność prowadzącą do zakleszczenia (deadlock) typu AA. Problem występuje, gdy operacja dodania przepływu FDB (Forwarding Database) w TC (Traffic Control) nie powiedzie się na niższym poziomie, a następnie usunięcie przepływu (mlx5e_tc_del_flow) próbuje ponownie uzyskać blokadę devcom, która jest już trzymana w przypadku przepływów peer. Powoduje to rekurencyjne zablokowanie (lockdep: possible recursive locking detected).

Ocena ryzyka

Zakleszczenie może doprowadzić do zawieszenia się systemu lub sterownika sieciowego, co skutkuje brakiem działania interfejsów sieciowych i potencjalną awarią usług sieciowych w środowisku produkcyjnym.

Rekomendacja

Zastosuj aktualizację jądra Linux zawierającą poprawkę (wprowadzenie flagi PEER i sprawdzanie jej przed pobraniem blokady devcom). Jeśli nie jest to możliwe, ogranicz użycie funkcji TC flower na interfejsach mlx5e do czasu wdrożenia poprawki.

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/mlx5e: TC, Check if flow is PEER before acquiring devcom lock In case __mlx5e_add_fdb_flow() fails in lower levels, the flow is deleted via mlx5e_tc_del_flow(), and mlx5e_tc_del_flow() is acquiring ESW devcom lock without condition. In addition, in case of peer_flow, __mlx5e_add_fdb_flow() is called while holding ESW devcom comp lock. This results in an AA deadlock. To fix this, introduce a new PEER flag that is set on flows created as peer flows (the duplicate flows on peer devices), and check it in mlx5e_tc_del_flow() before acquiring ESW devcom lock. Lockdep splat: ============================================ WARNING: possible recursive locking detected ============================================ Possible unsafe locking scenario: CPU0 ---- lock(&comp->lock_key#2); lock(&comp->lock_key#2); *** DEADLOCK *** Call Trace: <TASK> dump_stack_lvl+0x69/0xa0 print_deadlock_bug.cold+0xbd/0xca __lock_acquire+0x1671/0x2ec0 lock_acquire+0x10e/0x2e0 down_read+0x95/0x430 mlx5_devcom_for_each_peer_begin+0x4e/0xe0 [mlx5_core] mlx5e_tc_del_flow+0x11d/0xa70 [mlx5_core] mlx5e_flow_put+0x99/0x100 [mlx5_core] __mlx5e_add_fdb_flow+0x409/0xf00 [mlx5_core] mlx5e_configure_flower+0x2a86/0x4100 [mlx5_core] mlx5e_rep_setup_tc_cls_flower+0x12f/0x1b0 [mlx5_core] mlx5e_rep_setup_tc_cb+0x153/0x750 [mlx5_core] tc_setup_cb_add+0x1dc/0x470 fl_change+0x2f4d/0x626d [cls_flower] tc_new_tfilter+0x79b/0x2310 rtnetlink_rcv_msg+0x778/0xad0 do_syscall_64+0x70/0x960 entry_SYSCALL_64_after_hwframe+0x4b/0x53 </TASK>

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