CVE-2026-98068 in Linux
Sumário
de VulDB • 25/09/2026
No kernel do Linux, a seguinte vulnerabilidade foi resolvida:
net/rds: não permitir que rds_conn_shutdown() consuma uma queda concorrente
rds_conn_shutdown() termina movendo o caminho de RDS_CONN_DISCONNECTING para RDS_CONN_DOWN e também aceita RDS_CONN_ERROR como estado inicial dessa transição final, para que um FIN processado no contexto softirq durante a desmontagem não desvie o processo de encerramento para um caminho de erro ruidoso.
No entanto, consumir esse RDS_CONN_ERROR também consome a passagem de shutdown associada: rds_conn_path_drop() define RDS_CONN_ERROR e depois enfileira cp_down_w; uma passagem que começa em um caminho já no estado RDS_CONN_DOWN é uma operação nula (no-op). Para o caso FIN isso não prejudica - a soquete na qual o FIN chegou é exatamente a mesma soquete que a desmontagem acabou de liberar. Não é inofensivo para um dropper que anexou algo ao caminho primeiro.
rds_tcp_accept_one() é tal dropper. Sua reivindicação do caminho em rds_tcp_accept_one_path() transiciona RDS_CONN_DOWN -> RDS_CONN_CONNECTING, e uma queda concorrente - um FIN em uma soquete anterior no contexto softirq ou um reset administrativo - pode colocar o caminho em RDS_CONN_ERROR entre essa reivindicação e a verificação de estado subsequente que aceita RDS_CONN_ERROR. A aceitação então instala a soquete recém-aceita com rds_tcp_set_callbacks() enquanto a desmontagem enfileirada (que amostrou tc->t_sock antes dessa soquete existir) ainda está em execução. rds_connect_path_complete() falha na sua transição para RDS_CONN_UP e abandona o caminho novamente, enfileirando a passagem que deveria coletar a soquete que acabou de instalar. Se a transição final do shutdown em andamento consumir o RDS_CONN_ERROR dessa queda, a passagem enfileirada encontra o caminho no estado RDS_CONN_DOWN e não faz nada. A soquete instalada nunca é desmontada: ela permanece estabelecida com seus callbacks armados e seu rds_tcp_connection na lista rds_tcp_tc_list; o peer vê uma conexão que ninguém lê jamais, e o caminho fica preso em RDS_CONN_DOWN até algum evento posterior abandoná-lo novamente. Reproduzido com janelas de corrida ampliadas como uma fila de recebimento sempre crescente em uma soquete pertencente a um caminho travado no estado RDS_CONN_DOWN, com o caminho de envio do peer bloqueado atrás disso.
Faça a transição final apenas DISCONNECTING -> DOWN. Se falhar porque o caminho está em RDS_CONN_ERROR, significa que houve uma queda concorrente à desmontagem: cancele o timer de reconexão e limpe RDS_RECONNECT_PENDING - a única parte da cauda ignorada que não deve ser deixada para trás - e retorne, permitindo que a passagem enfileirada pela queda conclua o trabalho: ela desmonta qualquer coisa anexada ao caminho nesse meio tempo, completa a transição para RDS_CONN_DOWN e rearma a reconexão a partir de sua própria cauda.
A quiescência do timer nessa ramificação é importante porque a queda concorrente nem sempre enfileira essa passagem: rds_conn_path_drop() retorna sem enfileirar quando uma destruição está pendente - exatamente a situação durante o teardown de netns ou unload de módulo, quando um FIN na soquete moribunda é processado enquanto rds_conn_path_destroy() esvazia cp_down_w. Se a passagem esvaziada for aquela que causa esse retorno, não existe nenhuma passagem posterior e rds_conn_path_destroy() encontraria cp_conn_w ainda armado (WARN_ON) e então liberaria um caminho cujo timer de reconexão ainda pode disparar. Com o cancelamento na ramificação, toda saída de uma passagem de shutdown deixa o timer quiescente independentemente de qual passagem completa a transição.
O caso FIN continua progredindo, uma passagem depois e ainda sem logs ruidosos. Qualquer outro estado mantém o tratamento atual do rds_conn_path_error(); nenhum escritor cp_state atual pode deixar um caminho DISCONNECTING em qualquer coisa que não seja RDS_CONN_ERROR (todo outro escritor é um cmpxchg a partir de um estado não-DISCONNECTING), portanto essa ramificação é defensiva.
Em kernels sem os patches anteriores, o mesmo perigo existe com a quiescência baseada em amostragem; a correção se aplica igualmente lá.
If you want to get best quality of vulnerability data, you may have to visit VulDB.