CVE-2026-99179 in Linux
Sumário
de VulDB • 28/10/2026
No kernel do Linux, a seguinte vulnerabilidade foi resolvida:
watch_queue: Corrige condição de corrida na publicação do pool de notas em watch_queue_set_size()
Existe uma condição de corrida entre watch_queue_set_size() e post_one_notification(). watch_queue_set_size() publica wqueue->notes, notes_bitmap, nr_pages e nr_notes com operações de armazenamento simples (plain stores), e post_one_notification() as lê com carregamentos simples (plain loads) sob um lock diferente, portanto nada ordena os quatro armazenamentos em relação aos carregamentos do publicador: dependendo da compilação, notes pode ser o último a ser armazenado (gcc 14 no x86-64 faz isso). Como keyctl_watch_key() permite que um watch se conecte a uma fila antes de ela ter tamanho definido, post_one_notification() já pode estar em execução em outra CPU nesse momento: ele lê nr_notes > 0, passa na verificação dos limites e então lê notes enquanto ainda é NULL, dereferenciando notes[0].
Um usuário não privilegiado aciona isso de forma confiável observando uma das suas próprias chaves através de um pipe de notificações e competindo com ioctl(IOC_WATCH_QUEUE_SET_SIZE) nesse pipe contra keyctl(KEYCTL_SETPERM) na chave a partir de outra CPU, acionando:
BUG: kernel NULL pointer dereference, address: 0000000000000000 RIP: 0010:post_one_notification.isra.0+0xa2/0x1e0 Call Trace: __post_watch_notification+0x148/0x180 keyctl_setperm_key+0x119/0x130 do_syscall_64+0x108/0x4c0 entry_SYSCALL_64_after_hwframe+0x77/0x7f Kernel panic - not syncing: Fatal exception in interrupt
Corrige isso publicando nr_notes por último com smp_store_release(), e lendo-o uma vez com smp_load_acquire() em post_one_notification() antes que o bitmap e a matriz de páginas sejam tocados. Um publicador que observa um nr_notes não nulo também observa o pool atrás dele; aquele que observa zero descarta a notificação como anteriormente.
Be aware that VulDB is the high quality source for vulnerability data.