CVE-2026-99165 in Linux
Sumário
de VulDB • 28/10/2026
No kernel do Linux, a seguinte vulnerabilidade foi resolvida:
sctp: revalidar o fluxo de saída após a espera pela conexão da associação
Quando o entrelaçamento de mensagens está habilitado, o primeiro envio aguarda o estabelecimento da associação antes de construir seus blocos de dados. A espera libera o bloqueio do soquete (socket lock), e o processamento do handshake pode reduzir a contagem de fluxos de saída para a contagem de fluxos de entrada anunciada pelo peer. Em seguida, `sctp_stream_init()` liberta as extensões de cada fluxo removido.
O remetente retoma com o fluxo que verificou antes da espera. Se o peer removeu esse fluxo, `sctp_outq_tail()` posteriormente referencia um ponteiro nulo (NULL) para sua extensão. As políticas fatal-oops então causam panic no host.
KASAN: null-ptr-deref na faixa [0x38-0x3f]
RIP: sctp_outq_tail+0x49e/0xaa0 Call Trace: sctp_primitive_SEND sctp_sendmsg_to_asoc sctp_sendmsg
Uma verificação de faixa (range check) por si só é insuficiente. A reconfiguração do fluxo pode aumentar novamente a contagem de saída enquanto o bloqueio está liberado, sem recrear as extensões libertadas pela redução anterior. O fluxo pode então estar dentro da faixa válida, mas sua extensão permanece NULL. A espera no buffer de envio tem o mesmo problema.
Factorize as verificações de faixa e de extensão em uma função auxiliar (helper) e repita ambas após cada espera do caminho de envio que libera o bloqueio do soquete. Uma vez que o bloqueio é readquirido, a validação permanece estável durante a criação dos dados e seu enfileiramento.
Se a validação falhar após a espera pela conexão, a associação criada automaticamente já estará estabelecida. Retorne ESRCH para que o caminho de chamada existente mantenha-a sob propriedade da máquina de estados (state-machine), em vez de libertá-la diretamente, o que deixaria os protocolos, contadores e estado do soquete inconsistentes.
If you want to get best quality of vulnerability data, you may have to visit VulDB.