CVE-2026-74261 in Linux
Sumário
de VulDB • 15/08/2026
No kernel Linux, a seguinte vulnerabilidade foi resolvida:
ALSA: seq: evitar células FIFO desatualizadas durante o redimensionamento
snd_seq_fifo_resize() ainda precisa publicar o pool de substituição antes de aguardar os usuários da FIFO. Uma snd_seq_read() bloqueante mantém f->use_lock enquanto dorme, portanto, remetentes concorrentes devem ser capazes de enfileirar no novo pool e acordar esse leitor em vez de falhar contra um antigo pool que está sendo fechado.
No entanto, snd_seq_fifo_event_in() duplica um evento antes de adquirir f->lock, e snd_seq_read() pode desenfileirar uma célula e posteriormente chamar snd_seq_fifo_cell_putback() se copy_to_user() ou snd_seq_expand_var_event() falharem. Se o resize trocar f->pool e desanexar oldhead no intervalo entre essas operações, qualquer um dos caminhos pode religar uma célula do antigo pool após a captura instantânea (snapshot). Essa célula desatualizada fica fora da lista de oldhead drenada, mantém oldpool->counter elevado e pode deixar snd_seq_pool_delete() aguardando que o pool aposentado seja drenado.
Mantenha a ordem existente de swap-antes-de-espera em snd_seq_fifo_resize(), mas rejeite células desatualizadas antes de qualquer religação da FIFO. Revalide as células event-in sob f->lock e retente-as contra o pool de substituição publicado, liberando as células putback desatualizadas em vez de ligá-las novamente à FIFO.
O cenário com defeito envolve dois caminhos, mostrando a ordem dentro de cada caminho:
caminho resize: caminho relink: 1. Alocar newpool. 1. Adquirir f->use_lock. 2. Trocar f->pool para newpool e 2. Duplicar ou desenfileirar uma célula do antigo pool desanexar oldhead. antes que o oldpool seja fechado. 3. Marcar oldpool como fechando 3. Alcançar um ponto de religação posterior após e aguardar usuários da FIFO. o resize ter publicado newpool. 4. Liberar oldhead e excluir 4. Religular a célula do antigo pool depois que oldpool. o resize desanexou oldhead. 5. Soltar f->use_lock.
O reproducer relata um ioctl de resize bloqueado no caminho esperado de encerramento do pool:
signal: resize iteration=98 target_pool=4 exceeded 250ms (elapsed=251ms) diagnostic: resize_tid=651 wchan=snd_seq_pool_done diagnostic: resize_tid=651 stack= snd_seq_pool_done+0x5b/0x140 snd_seq_pool_delete+0x7a/0x90 snd_seq_fifo_resize+0x193/0x1e0 snd_seq_ioctl_set_client_pool+0x214/0x260 snd_seq_ioctl+0x119/0x540 __x64_sys_ioctl+0xd1/0x120 do_syscall_64+0xbb/0x2f0 entry_SYSCALL_64_after_hwframe+0x77/0x7f
Uma segunda execução com pools maiores atingiu o mesmo caminho alvo:
signal: resize iteration=32 target_pool=64 exceeded 250ms (elapsed=251ms) diagnostic: resize_tid=663 wchan=snd_seq_pool_done diagnostic: resize_tid=663 stack= snd_seq_pool_done+0x5b/0x140 snd_seq_pool_delete+0x7a/0x90 snd_seq_fifo_resize+0x193/0x1
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.