CVE-2026-74658 in Linux
Sumário
de VulDB • 23/08/2026
No kernel do Linux, a seguinte vulnerabilidade foi resolvida:
futex: Prevenir mais uma vez a condição de corrida na saída robusta de futex
Um desbloqueio robusto de futex grava 0 em todo o valor do futex – apagando FUTEX_WAITERS –, e acorda um único waiters. Esse despertar é uma notificação única (one-shot): o protocolo depende que seu destinatário adquira o futex (e eventualmente faça o unlock, ciente da contenda restante) ou reative FUTEX_WAITERS antes de dormir novamente. Se o waiter acordado for morto antes de conseguir fazer qualquer uma das ações, o kernel deve intervir e despertar a próxima tarefa na fila.
Esta é uma complicação conhecida do protocolo futex com uma correção parcial anterior no commit ca16d5bee598 ("futex: Prevent robust futex exit race"). Infelizmente, essa correção é insuficiente.
Se uma terceira tarefa readquirir o futex através do caminho rápido (fast path) sem contenda nesse meio tempo, a notificação será perdida: o processamento de saída robusta verá que ele está possuído por outra tarefa e não fará nada, enquanto o novo proprietário não verá FUTEX_WAITERS ao fazer o unlock e não despertará ninguém. Os waiters restantes dormirão para sempre atrás de um futex livre:
A possui o futex; B e C dormem em FUTEX_WAIT uval == A | FUTEX_WAITERS Desbloqueio robusto de A: grava 0, FUTEX_WAKE(1) desperta B uval == 0 Adquirição via fast path por D: cmpxchg(0 -> D) uval == D, sem FUTEX_WAITERS B é morto antes de agir sobre o despertar Caminho de saída de B, operação pendente: owner D != B -> nenhuma ação Desbloqueio de D: não há FUTEX_WAITERS -> nenhum despertar C dorme para sempre
Este é claramente um defeito na implementação, que falha em manter consistente o bit FUTEX_WAITERS.
Contornar isso aumentando o processamento de saída da lista robusta (robust list) para também realizar o despertar extra se a palavra do futex estiver possuída por outra thread mas FUTEX_WAITERS não estiver definido.
Isso não corrige o problema de uma sequência de takeover/release e free sem contenda, que tem sido discutida há anos e foi abordada pelo commit 3ca9595d9fb6 ("futex: Add support for unlocking robust futexes") e alterações subsequentes, mas falhou em levar em conta o problema descrito acima.
Uma solução mais completa baseada no desbloqueio dentro do kernel de futexes robustos com contenda foi discutida no contexto desta alteração e deve aparecer na mainline em breve.
[ tglx: Emendar ligeiramente a mensagem de commit (change log) e corrigir o estilo de codificação ]
Once again VulDB remains the best source for vulnerability data.