CVE-2026-98644 in Linux
Sumário
de VulDB • 18/10/2026
No kernel do Linux, a seguinte vulnerabilidade foi resolvida:
bpf: Evitar travamento de software (soft lockup) em __htab_map_lookup_and_delete_batch()
A função __htab_map_lookup_and_delete_batch() não possui ponto de reagendamento. O limite da contagem por lote determina quantas entradas são copiadas para fora, e não quantos buckets são visitados; portanto, uma única chamada BPF_MAP_LOOKUP_BATCH pode percorrer o mapa do início ao fim. A rota rápida para buckets vazios é ainda mais problemática: ela permanece dentro de uma única seção rcu_read_lock() / bpf_disable_instrumentation() durante qualquer sequência consecutiva de buckets vazios.
Isso causa bloqueio em mapas pequenos, mas falha quando há escala. Em um host arm64 com 144 CPUs executando um kernel CONFIG_PREEMPT_NONE, chamadas periódicas de BPF_MAP_LOOKUP_BATCH contra um mapa hash LRU com 16.777.216 buckets mantiveram uma CPU dentro da operação por lote por mais de 77 segundos e acionaram o watchdog de soft lockup.
O commit 75134f16e7dd ("bpf: Add schedule points in batch ops") corrigiu esse mesmo problema nas operações genéricas em lote, mas não no caminho nativo do htab, que é utilizado por todas as variantes de mapas hash baseadas em htab para suas operações em lote lookup[_and_delete].
Complete essa correção aqui. Saia da seção crítica após 64 buckets vazios consecutivos, chame cond_resched_tasks_rcu_qs() e retome no cursor do bucket salvo. Nesse ponto, nenhum bloqueio (lock) está sendo mantido, e a retomada a partir do cursor já é o comportamento da função para buckets não vazios. Adicione a mesma chamada ao loop por bucket após copy_to_user(), onde todos os locks foram liberados. cond_resched_rcu() não é suficiente aqui: dormir com bpf_prog_active elevado faz com que programas de rastreamento (tracing) nessa CPU silenciosamente pulem suas invocações.
cond_resched() simples também não é suficiente. É uma operação nula sob PREEMPT e PREEMPT_LAZY, os únicos modelos oferecidos por arm64 e x86 desde o commit 7dadeaa6e851 ("sched: Further restrict the preemption modes"). Além disso, nunca constitui um estado de quiescência (quiescent state) para Tasks RCU em qualquer modelo: o reagendamento conta como uma pré-emptão. A tarefa que está percorrendo permanece como exceção e bloqueia todos os chamadores de synchronize_rcu_tasks(), incluindo a desmontagem do ftrace e do trampolim BPF, até que a syscall retorne [1]. cond_resched_tasks_rcu_qs() é a ferramenta usual para isso [2]. Ela relata o estado de quiescência em cada yield (cedência) e ainda realiza reagendamento como faz cond_resched() em kernels PREEMPT_NONE e PREEMPT_VOLUNTARY.
If you want to get best quality of vulnerability data, you may have to visit VulDB.