Desconhecida

CVE-2026-93241 — memcg: bypass the reclaim and oom killer for dying tasks once oom_reaper is done

In the Linux kernel, the following vulnerability has been resolved: memcg: bypass the reclaim and oom killer for dying tasks once oom_reaper is done At Meta, we are seeing instances where an OOM killed job is stuck in the exit path for several hours. In one particular case, the job was stuck for more than 8 hours and I had to manually remove the memory.max limits to allow the process to exit. The job was a single process job and had ~55 GiB memory.max and zswap enabled. It had almost 0 anon in memory and ~111 GiB in zswap compressed to ~51 GiB zswap pool (i.e. almost all of memory.current was zswap). Nothing was left on the LRUs to reclaim. On further inspection, I observed ~20k threads of that process stuck with the following stack: [<0>] mem_cgroup_out_of_memory+0x4e/0xa0 [<0>] charge_memcg+0x8bf/0x990 [<0>] mem_cgroup_swapin_charge_folio+0x4e/0x80 [<0>] __read_swap_cache_async+0x10c/0x260 [<0>] swapin_readahead+0x116/0x3f0 [<0>] do_swap_page+0x13c/0x1ce0 [<0>] handle_mm_fault+0x61d/0x11f0 [<0>] do_user_addr_fault+0x3e7/0x6d0 [<0>] exc_page_fault+0x8f/0x110 [<0>] asm_exc_page_fault+0x22/0x30 [<0>] __get_user_8+0x14/0x20 [<0>] futex_cleanup+0x27/0x1c0 [<0>] futex_exit_release+0x47/0x60 [<0>] do_exit+0x107/0x940 [<0>] do_group_exit+0x81/0xa0 [<0>] get_signal+0x2b1/0x6e0 [<0>] arch_do_signal_or_restart+0x1a/0x1c0 [<0>] exit_to_user_mode_loop+0xa8/0x1c0 [<0>] do_syscall_64+0x152/0x250 [<0>] entry_SYSCALL_64_after_hwframe+0x4b/0x53 In addition the dmesg was filled with "Out of memory and no killable processes..." messages. I have no idea why oom reaper was not able to reap/unmap the process. My guess is that since oom reaper tries to acquire mmap_lock in read mode limited number of times and then gives up, there might be a thread of that process which had mmap_lock in write mode at that time. My initial suspicion was the futex_cleanup and kernel page fault causing infinite fault and charge retries but that was put to rest in previous discussions happened on similar problem [1]. My current theory is that it is just a simple slow serialization behind the oom_lock. Unlike page allocator, memcg charge code takes the oom_lock without the "try". Though memcg oom code uses mutex_lock_killable(), note that in the call stack get_signal() consumes SIGKILL (or sigdelset(SIGKILL)) before calling do_group_exit(). So this mutex_lock_killable() is just a mutex_lock() here. Therefore 10s of thousands of threads are waiting on oom_lock and one by one they get -EFAULT from get_user() in the futex cleanup code and bails out. Discussion from [1] led to commit a75ffa26122b ("memcg, oom: do not bypass oom killer for dying tasks") which routes dying tasks into the OOM path precisely so the oom_reaper can reap their mm and free the memory asynchronously. But the reaper is best-effort and one-shot: if it cannot take mmap_lock for read (e.g. a sibling thread holds it for write) it sets MMF_OOM_SKIP and never retries, leaving only the glacial oom_lock-serialized synchronous drain. Once MMF_OOM_SKIP is set there is no more asynchronous reclaim coming for the mm, so a dying task charging against it has nothing left to wait for: it frees its memory only once it finishes exiting. Running reclaim and the (no-victim) OOM killer for it is then pointless, and doing it for 10s of thousands of exiting threads is what serializes them behind oom_lock. So before reclaim, if current is an OOM victim whose reaper is done, fail the charge. Reproduced with 20k threads, each parking a robust futex head on its own zswapped page, OOM-group-killed while a sibling holds mmap_lock for write so the reaper gives up and sets MMF_OOM_SKIP. Tested on next-20260728 and baseline show ~90 seconds exit time while with the patch the exit time reduced to ~3 seconds.

Descrição oficial em inglês (tradução ainda não revisada).

Publicada em 24/09/2026 · Atualizada em 15/10/2026 · Fontes: NIST National Vulnerability Database, CVE Program (cve.org) e CISA ADP · CNA: Linux

Baixa

Quem explora e qual a prioridade

Nota de 0 a 100 que combina exploração confirmada, uso por ransomware e grupos APT, exploits públicos, EPSS e severidade.

Nenhum sinal de exploração nas fontes consultadas até agora.

Como a nota foi calculada

EPSS 0.2% (probabilidade de exploração em 30 dias)+2

A nota ordena a fila de correção; não substitui o contexto dos seus ativos (exposição à internet, criticidade, compensações).

Triagem

Está sendo explorada, qual a probabilidade de exploração, o que afeta e qual a severidade segundo as fontes.

Exploração

Não confirmada

Fora da CISA KEV — ausência de registro, não prova de que não é explorada.

EPSS FIRST

0,23%

à frente de 13% das CVEs pontuadas · 16/10/2026

Afeta

Linux

CVSS base

—

Pontuação ainda não publicada.

Remediação

Correções e mitigações documentadas pelas fontes — com link para o aviso original.

Nenhuma correção documentada pelas fontes consultadas. Isso não significa que não exista: verifique o aviso do fabricante.

Primeiras 24 horas

Ordenado a partir dos próprios campos do registro — exposição primeiro, porque não se corrige o que não se encontrou. Ponto de partida, gerado por regras.

Identifique ativos expostos que executam as combinações de fabricante/produto/versão afetadas (Linux Linux).
Nenhuma correção documentada nas fontes: reduza a exposição e monitore o aviso do fabricante.
Procure nos logs disponíveis sinais de tentativa de exploração, erros e anomalias de autenticação.

Escopo afetado

Fabricante, produto e versões como as fontes os descrevem.

Fabricante	Produto	Versões	Status	Fonte
Linux	Linux	≥ a75ffa26122bba4a3fa9372aa13b32d7a5590425 e < 801bcbdbfd595cc7f0de95f2802b5596c8971315≥ a75ffa26122bba4a3fa9372aa13b32d7a5590425 e < d44c3c5986c7a4a5f913a813e18cda08a838f91b≥ a75ffa26122bba4a3fa9372aa13b32d7a5590425 e < 6b0d1083364fc8e7cc2f7d1f93ee3ee78f4d52f7versão 6.16	Vulnerável	CVE Program (cve.org) e CISA ADP

EPSS ao longo do tempo FIRST

15/10/2026 → 16/10/2026 · 2 leitura(s) · máximo 0.23%

Detecção

Derivado do vetor CVSS e da classe da fraqueza. Pontos de partida, não regras testadas.

Sem vetor ou classe de fraqueza suficientes: use os logs da aplicação afetada como ponto de partida.

logs da aplicação

Linha do tempo

O que aconteceu com esta CVE, do mais recente ao mais antigo.

2026
Ficha publicada
15/10/2026
Produtos afetados adicionados · linux/linux
15/10/2026 · CVE Program (cve.org) e CISA ADP
Status na fonte alterado · → Received
15/10/2026 · NIST National Vulnerability Database
Registro criado nesta base
15/10/2026 · NIST National Vulnerability Database
CVE publicada
24/09/2026 · Linux

Atividade das fontes

Leituras que se repetem foram contadas em vez de listadas.

1× Descrição oficial atualizada · 15/10/2026 – 15/10/2026

Referências

3 no registro

git.kernel.org/stable/c/d44c3c5986c7a4a5f913a813e18cda08a838f91b
NIST National Vulnerability Database
git.kernel.org/stable/c/801bcbdbfd595cc7f0de95f2802b5596c8971315
NIST National Vulnerability Database
git.kernel.org/stable/c/6b0d1083364fc8e7cc2f7d1f93ee3ee78f4d52f7
NIST National Vulnerability Database

Em outras páginas do site

Linux
todas as CVEs deste fabricante

CVEs relacionadas (mesmos produtos)

Crítica CVE-2026-99999 ipv4: validate checksum_start before completing checksum 2 d
Desconhecida CVE-2026-98432 ipv4: free inet_opt and ireq_opt after an RCU grace period 2 d
Desconhecida CVE-2026-98424 wifi: cfg80211: undo netns switch if renaming the wiphy fails 3 d
Desconhecida CVE-2026-98425 wifi: mac80211: don't warn when an IBSS has no channel to scan 3 d
Desconhecida CVE-2026-98426 wifi: mwifiex: fix IRQ leak using wrong index in MSI-X error path 3 d
Desconhecida CVE-2026-98427 net/sched: codel: bound the dropping loop per dequeue call 3 d

Não consta em nenhuma fonte consultada

Listado em vez de deixado em branco: um campo vazio e um não medido parecem iguais na tela, e só um deles é motivo para procurar em outro lugar.

Nenhuma pontuação CVSS publicada por NVD, CNA, CISA ou GitHub até agora.
Nenhuma versão corrigida, patch ou mitigação documentada.
Sem avaliação SSVC da CISA.
Sem classificação CWE.
Nenhum IOC confirmado (IPs, domínios, hashes ou artefatos de malware) fornecido.
Nenhum inventário de ativos, controle compensatório ou evidência de implantação de patch da sua organização.
Nenhuma captura de tráfego de exploração, amostra de log ou caso de incidente.

Respondido a partir deste registro

Texto montado apenas com os campos acima — sem afirmações adicionais.

O que os defensores devem saber primeiro?

CVE-2026-93241 é "memcg: bypass the reclaim and oom killer for dying tasks once oom_reaper is done", de severidade Desconhecida. Afeta Linux (Linux); as versões estão na tabela de escopo. Não está na CISA KEV, o que não exclui exploração. EPSS 0.23% estima a probabilidade de exploração em 30 dias; nenhum dos dois substitui o contexto dos seus ativos. Verifique primeiro se ativos expostos ou críticos executam as versões afetadas, aplique as correções ou mitigações do fabricante e preserve logs para análise.

Comentários

Discussão técnica moderada. Leia as regras da comunidade.

Nenhum comentário ainda.

Entre ou crie uma conta para comentar e sugerir correções.