CVE-2026-98068 — net/rds: don't let rds_conn_shutdown() consume a concurrent drop
In the Linux kernel, the following vulnerability has been resolved: net/rds: don't let rds_conn_shutdown() consume a concurrent drop rds_conn_shutdown() finishes by moving the path from RDS_CONN_DISCONNECTING to RDS_CONN_DOWN, and also accepts RDS_CONN_ERROR as the starting state of that final transition, so that a FIN processed in softirq context during the teardown does not derail the shutdown into a noisy error path. But consuming that RDS_CONN_ERROR also consumes the shutdown pass that came with it: rds_conn_path_drop() sets RDS_CONN_ERROR and then queues cp_down_w, and a pass that starts on a path already in RDS_CONN_DOWN is a no-op. For the FIN case that is harmless - the socket the FIN arrived on is the very socket the teardown just released. It is not harmless for a dropper that attached something to the path first. rds_tcp_accept_one() is such a dropper. Its path claim in rds_tcp_accept_one_path() transitions RDS_CONN_DOWN -> RDS_CONN_CONNECTING, and a concurrent drop - a FIN on a previous socket in softirq context, an administrative reset - can put the path into RDS_CONN_ERROR between that claim and the state check that follows, which accepts RDS_CONN_ERROR. The accept then installs the freshly accepted socket with rds_tcp_set_callbacks() while the queued teardown - which sampled tc->t_sock before this socket existed - is still running. rds_connect_path_complete() fails its transition to RDS_CONN_UP and drops the path again, queueing the pass that should reap the socket it just installed. If the in-flight shutdown's final transition consumes that drop's RDS_CONN_ERROR, the queued pass finds the path in RDS_CONN_DOWN and does nothing. The installed socket is never torn down: it sits established with its callbacks armed and its rds_tcp_connection on rds_tcp_tc_list, the peer sees a connection that nothing ever reads, and the path is wedged in RDS_CONN_DOWN until some later event drops it again. Reproduced with widened race windows as an ever-growing receive queue on a socket owned by a path stuck in RDS_CONN_DOWN, with the peer's send path wedged behind it. Make the final transition only DISCONNECTING -> DOWN. If it fails because the path is in RDS_CONN_ERROR, a drop raced the teardown: cancel the reconnect timer and clear RDS_RECONNECT_PENDING - the one piece of the skipped tail that must not be left behind - and return, letting the pass the drop queued finish the job: it tears down whatever attached to the path in the meantime, completes the transition to RDS_CONN_DOWN, and re-arms the reconnect from its own tail. The timer quiesce in that branch matters because the racing drop does not always queue that pass: rds_conn_path_drop() returns without queueing when a destroy is pending - exactly the situation during a netns teardown or module unload, when a FIN on the dying socket is processed while rds_conn_path_destroy() flushes cp_down_w. If the flushed pass is the one that takes this return, no later pass exists, and rds_conn_path_destroy() would find cp_conn_w still armed (WARN_ON) and then free a path whose reconnect timer can still fire. With the cancel in the branch, every exit of a shutdown pass leaves the timer quiesced no matter which pass completes the transition. The FIN case keeps making progress, one pass later and still without noisy logging. Any other state keeps today's rds_conn_path_error() handling; no current cp_state writer can leave a DISCONNECTING path in anything but RDS_CONN_ERROR (every other writer is a cmpxchg from a non-DISCONNECTING state), so that branch is defensive. On kernels without the preceding patches the same hazard exists with the sample-based quiesce; the fix applies there equally.
Descrição oficial em inglês (tradução ainda não revisada).
Quem explora e qual a prioridade
Nota de 0 a 100 que combina exploração confirmada, uso por ransomware e grupos APT, exploits públicos, EPSS e severidade.
Como a nota foi calculada
- EPSS 0.2% (probabilidade de exploração em 30 dias)+1
A nota ordena a fila de correção; não substitui o contexto dos seus ativos (exposição à internet, criticidade, compensações).
Triagem
Está sendo explorada, qual a probabilidade de exploração, o que afeta e qual a severidade segundo as fontes.
Remediação
Correções e mitigações documentadas pelas fontes — com link para o aviso original.
Nenhuma correção documentada pelas fontes consultadas. Isso não significa que não exista: verifique o aviso do fabricante.
Primeiras 24 horas
Ordenado a partir dos próprios campos do registro — exposição primeiro, porque não se corrige o que não se encontrou. Ponto de partida, gerado por regras.
- Identifique ativos expostos que executam as combinações de fabricante/produto/versão afetadas (Linux Linux).
- Nenhuma correção documentada nas fontes: reduza a exposição e monitore o aviso do fabricante.
- Procure nos logs disponíveis sinais de tentativa de exploração, erros e anomalias de autenticação.
Escopo afetado
Fabricante, produto e versões como as fontes os descrevem.
| Fabricante | Produto | Versões | Status | Fonte |
|---|---|---|---|---|
| Linux | Linux |
≥ e97656d03ca0cea888a0b9d382abce8233771f31 e < f777c602d3e15d3414b53f760147687bd56b03f2≥ e97656d03ca0cea888a0b9d382abce8233771f31 e < 7cb11257aa3e5ef0bedfd5d55ac60bb00347aa97≥ e97656d03ca0cea888a0b9d382abce8233771f31 e < 4980ce260205001d582a7b3cb5eab29877777fbc≥ e97656d03ca0cea888a0b9d382abce8233771f31 e < 0ec75c69918b7f6a1a5e3fb6442925246a9ec86b≥ e97656d03ca0cea888a0b9d382abce8233771f31 e < bd1cb197a07111ca8d4f4c21411c56a3c85a9797≥ e97656d03ca0cea888a0b9d382abce8233771f31 e < 4cb9b6d3d31a2dbaa5469981c2c4c03e9acc7aca≥ e97656d03ca0cea888a0b9d382abce8233771f31 e < 2941561395066be856a53626d4ca973dd9c982b2≥ e97656d03ca0cea888a0b9d382abce8233771f31 e < 260c6308fe2e19ad519389d44d582e292aecc3af e mais 1versão 4.12 |
Vulnerável | CVE Program (cve.org) e CISA ADP |
EPSS ao longo do tempo FIRST
15/10/2026 → 16/10/2026 · 2 leitura(s) · máximo 0.18%
Detecção
Derivado do vetor CVSS e da classe da fraqueza. Pontos de partida, não regras testadas.
- Sem vetor ou classe de fraqueza suficientes: use os logs da aplicação afetada como ponto de partida.
Linha do tempo
O que aconteceu com esta CVE, do mais recente ao mais antigo.
- 2026
- Ficha publicada
- Produtos afetados adicionados · linux/linux
- Status na fonte alterado · → Undergoing Analysis
- Registro criado nesta base
- CVE publicada
Atividade das fontes
Leituras que se repetem foram contadas em vez de listadas.
- 1× Descrição oficial atualizada · 15/10/2026 – 15/10/2026
Referências
8 no registro
- git.kernel.org/stable/c/bd1cb197a07111ca8d4f4c21411c56a3c85a9797
- git.kernel.org/stable/c/f777c602d3e15d3414b53f760147687bd56b03f2
- git.kernel.org/stable/c/0ec75c69918b7f6a1a5e3fb6442925246a9ec86b
- git.kernel.org/stable/c/4980ce260205001d582a7b3cb5eab29877777fbc
- git.kernel.org/stable/c/4cb9b6d3d31a2dbaa5469981c2c4c03e9acc7aca
- git.kernel.org/stable/c/2941561395066be856a53626d4ca973dd9c982b2
- git.kernel.org/stable/c/260c6308fe2e19ad519389d44d582e292aecc3af
- git.kernel.org/stable/c/7cb11257aa3e5ef0bedfd5d55ac60bb00347aa97
Em outras páginas do site
CVEs relacionadas (mesmos produtos)
- Crítica CVE-2026-99999 ipv4: validate checksum_start before completing checksum 2 d
- Desconhecida CVE-2026-98432 ipv4: free inet_opt and ireq_opt after an RCU grace period 2 d
- Desconhecida CVE-2026-98431 RDMA/uverbs: Fix mmap_lock/disassociation_lock circular dependency 3 d
- Desconhecida CVE-2026-98424 wifi: cfg80211: undo netns switch if renaming the wiphy fails 3 d
- Desconhecida CVE-2026-98425 wifi: mac80211: don't warn when an IBSS has no channel to scan 3 d
- Desconhecida CVE-2026-98426 wifi: mwifiex: fix IRQ leak using wrong index in MSI-X error path 3 d
Não consta em nenhuma fonte consultada
Listado em vez de deixado em branco: um campo vazio e um não medido parecem iguais na tela, e só um deles é motivo para procurar em outro lugar.
- Nenhuma pontuação CVSS publicada por NVD, CNA, CISA ou GitHub até agora.
- Nenhuma versão corrigida, patch ou mitigação documentada.
- Sem avaliação SSVC da CISA.
- Sem classificação CWE.
- Nenhum IOC confirmado (IPs, domínios, hashes ou artefatos de malware) fornecido.
- Nenhum inventário de ativos, controle compensatório ou evidência de implantação de patch da sua organização.
- Nenhuma captura de tráfego de exploração, amostra de log ou caso de incidente.
Respondido a partir deste registro
Texto montado apenas com os campos acima — sem afirmações adicionais.
O que os defensores devem saber primeiro?
CVE-2026-98068 é "net/rds: don't let rds_conn_shutdown() consume a concurrent drop", de severidade Desconhecida. Afeta Linux (Linux); as versões estão na tabela de escopo. Não está na CISA KEV, o que não exclui exploração. EPSS 0.18% estima a probabilidade de exploração em 30 dias; nenhum dos dois substitui o contexto dos seus ativos. Verifique primeiro se ativos expostos ou críticos executam as versões afetadas, aplique as correções ou mitigações do fabricante e preserve logs para análise.
Comentários
Discussão técnica moderada. Leia as regras da comunidade.
Nenhum comentário ainda.
Entre ou crie uma conta para comentar e sugerir correções.