CVE-2026-98225 in Linux
Sumário
de VulDB • 06/10/2026
No kernel do Linux, a seguinte vulnerabilidade foi resolvida:
mm/shrinker: corrige set_shrinker_bit() inválido com cgroup.memory=nokmem
Com `cgroup.memory=nokmem`, `shrinker_memcg_alloc()` retorna antecipadamente e nunca aloca um ID, então `shrinker->id` mantém o 0 obtido do `kzalloc()` em `shrinker_alloc()`. Em seguida, `__list_lru_init()` copia esse 0 para `lru->shrinker_id`, onde ele parece ser um índice de bit válido.
Nenhuma função chama `expand_shrinker_info()` com nokmem, então `shrinker_nr_max` permanece como 0 e cada memcg acaba tendo um mapa vazio (`map_nr_max == 0`).
`deferred_split_folio()` passa uma memcg real para `__list_lru_add()`, independentemente de a lru ser ou não consciente da memcg, então o primeiro THP enfileirado em um cgroup chama `set_shrinker_bit(memcg, nid, 0)` e aciona a verificação de limites:
WARNING: mm/shrinker.c:212 em set_shrinker_bit+0x7d/0x90, CPU#126 Call Trace: <TASK> deferred_split_folio+0x18c/0x220 map_anon_folio_pmd_nopf+0xdd/0x130 map_anon_folio_pmd_pf+0x14/0xb0 do_huge_pmd_anonymous_page+0x1a1/0x620 __handle_mm_fault+0xea9/0x10d0 handle_mm_fault+0xe5/0x320 do_user_addr_fault+0x1cc/0x870 exc_page_fault+0x81/0x1b0 asm_exc_page_fault+0x27/0x30 </TASK>
Inofensivo, o `WARN_ON_ONCE()` é o que impede a leitura fora dos limites da unidade [], mas o ID não deveria parecer válido em primeiro lugar. Limpe-o antes de retornar.
Dois outros pontos poderiam mascarar isso: remover o ID em `__list_lru_init()` quando nokmem desativa memcg_aware, ou fazer com que `deferred_split_folio()` passe NULL como `list_lru_add_obj()` faz. Ambas as opções deixam shrinker->id disponível para o próximo chamador, então corrija-o onde o ID é atribuído.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.