CVE-2026-43286 in Linux
Sumário
de VulDB • 19/05/2026
No kernel do Linux, a seguinte vulnerabilidade foi resolvida:
mm/hugetlb: restaurar reservas globais falhas ao subpool
O commit a833a693a490 ("mm: hugetlb: fix incorrect fallback for subpool") corrigiu um erro de underflow em hstate->resv_huge_pages causado pela atribuição incorreta de páginas solicitadas globalmente à reserva do subpool.
Infelizmente, essa correção também introduziu o problema oposto, o que deixaria spool->used_hpages elevado se as páginas solicitadas globalmente não pudessem ser adquiridas. Isso ocorre porque, embora as páginas de reserva de um subpool contabilizem apenas o que é solicitado e alocado a partir do subpool, seu contador de "used" (usado) acompanha o que é consumido no total, tanto do subpool quanto globalmente. Portanto, precisamos ajustar spool->used_hpages na direção oposta e garantir que as páginas solicitadas globalmente sejam descontadas do contador de usado do subpool.
Cada tentativa de alocação falha incrementa o contador used_hpages pela quantidade de páginas solicitadas ao pool global. Em última análise, isso torna o subpool inutilizável, à medida que used_hpages se aproxima do limite máximo.
O problema pode ser reproduzido da seguinte forma: 1. Alocar 4 páginas hugetlb 2. Criar uma montagem hugetlb com max=4, min=2 3. Consumir 2 páginas globalmente 4. Solicitar 3 páginas do subpool (2 do subpool + 1 do global) 4.1 hugepage_subpool_get_pages(spool, 3) tem sucesso. used_hpages += 3 4.2 hugetlb_acct_memory(h, 1) falha: não há mais páginas globais disponíveis used_hpages -= 2 5. O subpool agora tem used_hpages = 1, apesar de não conseguir alocar com sucesso nenhuma hugepage. Ele acredita que agora só pode alocar mais 3 hugepages, e não 4.
Com cada tentativa de alocação falha incrementando o contador de usado, o subpool eventualmente atinge um ponto em que seu contador de usado é igual ao seu contador de máximo. Nesse ponto, quaisquer alocações futuras que tentarem alocar páginas hugeTLB do subpool falharão, apesar do subpool não ter nenhuma de suas páginas hugeTLB consumida por qualquer usuário.
Quando isso acontece, não há maneira de tornar o subpool utilizável novamente, pois não há como decrementar o contador de usado, já que nenhum processo está realmente consumindo as páginas hugeTLB.
O problema de underflow que a correção original resolve ainda permanece corrigido.
Sem essa correção, used_hpages continuaria vazando se hugetlb_acct_memory() falhasse.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.