Katalog CVE

CVE-2026-64418

WysokieCVSS 7.8
Opublikowano: Zaktualizowano: Przetłumaczono: NVD NIST

Prawdopodobieństwo exploitacji (EPSS)

Niskie ryzyko
0.13%

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

Streszczenie

W jądrze Linux wykryto błąd w mechanizmie skalowania shrinker_info, który prowadzi do wyścigu podczas rozszerzania i usuwania tej struktury. Problem występuje, gdy expand_shrinker_info() iteruje po memcg, które nie zakończyły jeszcze procesu online, a jednocześnie alloc_shrinker_info() zwalnia pamięć poza sekcją chronioną mutexem. Może to skutkować podwójnym zwolnieniem pamięci (double-free) lub użyciem po zwolnieniu (use-after-free).

Ocena ryzyka

Organizacja narażona jest na niestabilność systemu, potencjalne awarie jądra (kernel panic) oraz ryzyko eskalacji uprawnień w wyniku wykorzystania błędu w zarządzaniu pamięcią. Podatność może być szczególnie niebezpieczna w środowiskach z dużą liczbą kontenerów lub cgroup.

Rekomendacja

Należy niezwłocznie zaktualizować jądro Linux do wersji zawierającej poprawkę (commit z rozwiązaniem problemu). Monitoruj oficjalne biuletyny bezpieczeństwa dystrybucji Linux w celu uzyskania łatki.

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: mm: shrinker: fix shrinker_info teardown race with expansion expand_shrinker_info() iterates all visible memcgs under shrinker_mutex, including memcgs that have not finished ->css_online() yet. Once pn->shrinker_info has been published, teardown must stay serialized with expand_shrinker_info() until that memcg is either fully online or no longer visible to iteration. Today alloc_shrinker_info() breaks that rule by dropping shrinker_mutex before freeing a partially initialized shrinker_info array, which may cause the following race: CPU0 CPU1 ==== ==== css_create --> list_add_tail_rcu(&css->sibling, &parent_css->children); online_css --> mem_cgroup_css_online --> alloc_shrinker_info --> alloc node0 info rcu_assign_pointer(C->node0->shrinker_info, old0) alloc node1 info -> FAIL -> goto err mutex_unlock(shrinker_mutex) shrinker_alloc() --> shrinker_memcg_alloc --> mutex_lock(shrinker_mutex) expand_shrinker_info --> mem_cgroup_iter see the memcg expand_one_shrinker_info --> old0 = C->node0->shrinker_info memcpy(new->unit, old0->unit, ...); free_shrinker_info --> kvfree(old0); /* double free !! */ kvfree_rcu(old0, rcu); The same problem exists later in mem_cgroup_css_online(). If alloc_shrinker_info() succeeds but a subsequent objcg allocation fails, the free_objcg -> free_shrinker_info() unwind path tears down the already published pn->shrinker_info arrays without shrinker_mutex. The expand_one_shrinker_info() can race with that teardown in the same way, leading to use-after-free or double-free of the old shrinker_info. Fix this by serializing shrinker_info teardown with shrinker_mutex, and by keeping alloc_shrinker_info() error cleanup inside the locked section.

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