CVE-2026-98432

Escrito por DeepSeek.

Um servidor TCP IPv4 simples é vulnerável. O MPTCP não é o gatilho.

Compilamos o Linux 6.18.55 a partir do tarball de lançamento e fizemos o kernel ler memória liberada em um listener IPPROTO_TCP normal. O KASAN reportou isso duas vezes. Nenhum socket MPTCP foi criado em momento algum, e uma das execuções tinha o MPTCP desativado no kernel.

O mesmo bug faz o kernel copiar bytes de um objeto liberado para a resposta que envia de volta. Essa é a primitiva de que um quebra de KASLR precisa, e observamos isso acontecer em trabalho não publicado. Nós não construímos um vazamento de endereço de kernel, e não provamos uma escrita.

O que está provado aqui, com código e logs: o use-after-free é real, o TCP padrão o alcança, e a correção upstream o impede.

As execuções

Kernel	MPTCP	Tentativas	Tempo	Resultado
6.18.55, sem correção	não usado	134.955	34 s	KASAN use-after-free
6.18.55, sem correção	desativado	191.431	80 s	KASAN use-after-free
6.18.55 + correção	não usado	439.316	411 s	limpo

Quão difícil é atingir?

Muito difícil. Com o KASAN o leitor é lento, então o bug aparece em algumas centenas de milhares de tentativas. Em um kernel normal é muito mais raro: em cerca de 48 milhões de tentativas vimos dois eventos, ambos dentro dos mesmos cinco segundos.

Isso é pouco demais para declarar uma taxa. O máximo que afirmaremos é um limite de aproximadamente 1e-7 por tentativa, e mesmo isso é um melhor caso, porque nosso harness força os dois pacotes em duas CPUs e uma NIC real geralmente envia um fluxo para uma CPU.

Portanto, uma execução limpa não significa um kernel seguro. Leia as seções 5.2 e 6 do ANALYSIS.md antes de citar qualquer número.

O bug em palavras simples

Um servidor TCP recebe um SYN. O SYN carrega uma opção IPv4 (Record Route ou Timestamp). O kernel salva essas opções no socket de requisição.

Um segundo SYN para a mesma conexão chega. O kernel constrói um SYNACK para ele e lê as opções salvas.

Ao mesmo tempo, o handshake termina. O socket filho recebe o mesmo ponteiro, não uma cópia. O servidor fecha o filho, e o kernel libera as opções com um kfree() simples.

O código do SYNACK ainda está lendo essa memória. Esse é o use-after-free. A mesma leitura é o que coloca bytes liberados no pacote.

O que este repositório não é

É um gatilho de bug, não um exploit. Não vaza endereços de kernel, não escreve na memória do kernel e não obtém root. Ele mostra o kernel lendo memória liberada; o KASAN é o juiz.

O repositório para aí de propósito. Estágios posteriores foram trabalhados em particular e não são publicados aqui.

Reproduza

scripts/get-kernel.sh              # fetch 6.18.55, sha256 checked, into linux/
scripts/build-kernel.sh vuln       # KASAN kernel, no fix
scripts/build-kernel.sh patched    # KASAN kernel, with the fix
scripts/build-harness.sh           # builds harness/init + initramfs
scripts/run.sh vuln 90 selftest    # checks the wiring only
scripts/run.sh vuln 600            # expect a KASAN report
scripts/run.sh patched 600         # expect nothing

Você precisa de gcc, make, bison, flex, bc e qemu-system-x86_64. O KVM ajuda bastante. A VM usa 2 GB de RAM e 8 vCPUs.

Uma execução pode não mostrar nada. Isso não é evidência de um kernel seguro. Execute várias vezes e leia as ressalvas em ANALYSIS.md.

Verifique seu próprio kernel

Não confie na string de versão. Examine o código no binário.

scripts/check-free-sites.py

Ele encontra os dois sites livres no kernel em execução e mostra qual função eles chamam: kfree (ruim) ou kvfree_call_rcu (corrigido).

Na máquina em que isto foi escrito (6.18.59_1), ambos os sites usam kvfree_call_rcu, portanto esse kernel está corrigido.

Quem está exposto

Um host está exposto se todas as três condições forem verdadeiras:

1. ele escuta em TCP IPv4, e
2. o par envia um SYN com opções IP, e
3. o programa fecha o socket aceito logo em seguida.

O atacante controla o ponto 2. Portanto, a maioria dos servidores de internet está exposta, e "não usamos MPTCP" não ajuda.

Duas observações:

• accept_source_route=0 não protege você. Ele apenas bloqueia source routing, não Record Route ou Timestamp.
• Se você ainda não pode aplicar o patch, descarte SYNs de entrada que carreguem opções IP. Assim o kernel nunca salva opções para o socket de requisição. Aplicar o patch é melhor.

Arquivos

Caminho	O que é
ANALYSIS.md	o relatório completo: caminho no código-fonte, método, resultados, limites
harness/	o gatilho do bug que roda como /init no QEMU
patches/	a correção upstream, usada para a build de controle
scripts/	auxiliares de busca, build, execução e verificação
evidence/	relatórios KASAN, logs de execução, comparação de builds

Escopo

Apenas kernels de teste, e apenas os que você possui. Nada aqui deve ser apontado para sistemas que você não controla.

Licença

MIT para nosso código e texto. patches/ contém um commit do kernel Linux e permanece sob GPL-2.0. Veja LICENSE.