Katalog CVE

CVE-2026-98286

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

Prawdopodobieństwo exploitacji (EPSS)

Niskie ryzyko
0.17%

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

Streszczenie

W jądrze Linux wykryto podatność w module drop_monitor, gdzie podczas wyłączania monitorowania per-CPU timery są zatrzymywane za pomocą timer_delete_sync(), co nie zapobiega ponownemu uzbrojeniu timera przez współbieżnie działający worker. W warunkach braku pamięci worker może ponownie uzbroić timer po zakończeniu timer_delete_sync(), a po odładowaniu modułu timer wywoła kod w zwolnionej pamięci, prowadząc do paniki jądra lub use-after-free.

Ocena ryzyka

Ryzyko obejmuje możliwość awarii systemu (kernel panic) lub wykorzystania podatności do wykonania kodu w kontekście jądra, co może prowadzić do przejęcia kontroli nad systemem lub jego destabilizacji.

Rekomendacja

Zaleca się natychmiastowe zaktualizowanie jądra Linux do wersji zawierającej poprawkę, która zastępuje timer_delete_sync() funkcją timer_shutdown_sync(). Należy również monitorować dostępność oficjalnych łat od dystrybutora.

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: drop_monitor: use timer_shutdown_sync() to prevent timer rearming during teardown In drop_monitor teardown paths (net_dm_trace_off_set(), net_dm_hw_monitor_stop(), and error unwind paths in net_dm_trace_on_set() and net_dm_hw_monitor_start()), per-CPU timers are stopped using timer_delete_sync() followed by cancel_work_sync(). However, there is a circular dependency between send_timer and dm_alert_work: 1) sched_send_work() (timer callback) schedules dm_alert_work. 2) send_dm_alert() / net_dm_hw_summary_work() calls reset_per_cpu_data() or net_dm_hw_reset_per_cpu_data(). 3) If memory allocation fails under memory pressure in the reset function, it re-arms the timer via mod_timer(&data->send_timer, ...). If dm_alert_work is running concurrently while timer_delete_sync() executes on another CPU, an allocation failure in the worker will re-arm the timer after timer_delete_sync() has already returned. Once cancel_work_sync() completes and module_put() is called, the timer remains active in the timer wheel. If the module is then unloaded, the timer will fire and execute sched_send_work() in freed memory, triggering a kernel panic / use-after-free. Switch from timer_delete_sync() to timer_shutdown_sync(). This guarantees that any in-flight timer handler has finished and prevents subsequent re-arming attempts from running workers from succeeding. When monitoring is restarted later, timer_setup() is invoked, which cleanly re-initializes the timer.

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