Katalog CVE

CVE-2026-93197

Nieznane
Opublikowano: Przetłumaczono: NVD NIST

Streszczenie

W jądrze Linux występuje błąd w mechanizmie memcg, w którym przy odłączaniu cgroup pamięci rozmiary LRU są kopiowane do rodzica zamiast być przenoszone, pozostawiając nieaktualne liczniki w dziecku. Powoduje to, że skaner LRU (lub MGLRU) odczytuje fałszywe rozmiary i wykonuje jałowe pętle skanowania na martwych cgroupach, co prowadzi do zawyżenia limitów i marnowania CPU. W jednym przypadku wykryto liczniki opisujące 476 GiB stron, czyli 1,89x więcej niż fizyczna pamięć hosta.

Ocena ryzyka

Organizacja może doświadczyć nadmiernego zużycia CPU przez jałowe skanowanie LRU na martwych cgroupach oraz błędnych decyzji o zarządzaniu pamięcią wynikających z zawyżonych liczników. Może to prowadzić do pogorszenia wydajności, a w skrajnych przypadkach do nieprawidłowego działania mechanizmów odzyskiwania pamięci.

Rekomendacja

Zaktualizuj jądro Linux do wersji zawierającej poprawkę dla CVE-2026-93197, pamiętając że wymaga ona wcześniejszego commitu bf4ade7dbd76 ("memcg: keep folio's objcg same as its node") i nie może być backportowana przed nim. Po aktualizacji zweryfikuj stabilność systemu i zużycie CPU na hostach z intensywnym użyciem cgroup pamięci.

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: memcg: move LRU size accounting on reparenting instead of copying it When a memory cgroup is offlined its LRU folios are reparented to the parent. lruvec_reparent_lru() splices the child's lists into the parent's and credits the parent with the child's per-zone lru_zone_size[], but never clears the child's copy, so the size is copied rather than moved. lru_gen_reparent_memcg() does the same for MGLRU. The parent is left correct, credited with exactly the folios it took over. The stale value sits on the child and nothing will correct it: folio->memcg_data now resolves to the parent, so every later update_lru_size() for those folios goes there. Dying cgroups are not freed immediately and mem_cgroup_iter() still walks them, so shrink_lruvec() keeps being called on them. get_scan_count() reads the phantom counter through lruvec_lru_size() and the scan loop then grinds through nr[] in SWAP_CLUSTER_MAX steps against an empty list, for as long as the dead cgroup lives. Under MGLRU the MGLRU scanner runs instead, but count_shadow_nodes() sums all of NR_LRU_LISTS through lruvec_lru_size() and over-budgets the shadow node limit just the same. On one 251 GiB host a sweep of every mz->lru_zone_size[] found 380 counters describing folios on no list at all: 124777314 pages, 476 GiB, 1.89x the machine's RAM, across 57 cgroups. All were on memcgs with CSS_DYING set and CSS_ONLINE clear, and parent/child pairs reported byte-identical sizes. LRU_UNEVICTABLE needs its size moved too. Its list is deliberately not spliced because lruvec_init() poisons the head - the unevictable LRU is imaginary and folios are never threaded on it - but the size is kept by lruvec_add_folio()/lruvec_del_folio() and those folios account to the parent from here on. This depends on commit bf4ade7dbd76 ("memcg: keep folio's objcg same as its node") and must not be backported ahead of it. Without that invariant a folio's objcg can belong to another node, so a folio already spliced onto the parent's list can still resolve to the child's lruvec until the objcg's node is reparented in a later iteration of memcg_reparent_objcgs(); clearing the child's counter early then lets lruvec_del_folio() underflow it and trip the WARN_ONCE()/VM_BUG_ON() in mem_cgroup_update_lru_size().

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