foxirain/linux-kernel-codex-harness-v2Harness de pesquisa de vulnerabilidades do kernel Linux com ciência de proveniência, utilizado na investigação da CVE-2026-53075
Ferramenta de Pesquisa · Importação Original: 3 de Abril de 2026 · Revisão da Documentação v2: 11 de Julho de 2026
Sinal Externo: Da Alocação de Atenção à Triagem Ciente de Proveniência
Use observações reproduzíveis para orientar a atenção do modelo e, em seguida, use a proveniência do repositório para organizar filas de revisão—nunca para reivindicar prova.
Linhagem do Projeto— Kernel Codex Harness v1 · Alocação de Atenção → Kernel Codex Harness v2 · Triagem Ciente de Proveniência
Status do projeto. Este repositório é um harness de pesquisa assistido por LLM que evoluiu o workflow de alocação de atenção do v1 para a triagem ciente de proveniência, destinado à investigação real de vulnerabilidades no kernel Linux. Esta versão foi usada para descobrir a vulnerabilidade divulgada como CVE-2026-53075. Não é um detector automático de vulnerabilidades, um avaliador de novidade, um validador de exploits ou uma ferramenta de garantia de segurança do kernel; a validação final e a divulgação são realizadas por humanos.
Abstract— Fazer um LLM explorar diretamente uma base de código tão grande quanto o kernel Linux dispersa o contexto e facilmente confunde a presença de APIs perigosas com a real explorabilidade. O Kernel Codex Harness v2 define esse problema em dois estágios de processamento de Sinal Externo. Antes da chamada do modelo, pesos de caminho, correspondências lexicais e sobreposição em cache com syzbot classificam arquivos candidatos para alocar atenção. Após a resposta do modelo, branch·HEAD·estado sujo do Git e referências CVE·commit·marcador conhecido extraídas da resposta são combinados para classificar achados fortes em buckets de revisão cientes de proveniência. Este harness foi usado em uma investigação real do kernel Linux que encontrou uma falha de verificação de permissão do namespace de rede alvo do PPP, divulgada como CVE-2026-53075. A triagem é uma heurística para organizar a fila de investigação; em particular, new_candidate significa apenas que nenhuma pista conhecida ou problema de proveniência foi encontrado, não é uma prova de novidade. Todos os achados exigem revalidação humana de alcançabilidade no espaço do usuário, quebra de invariante e impacto concreto.
Termos de Indexação— kernel Linux, pesquisa de vulnerabilidades, sinal externo, proveniência, triagem heurística, orquestração de LLM, syzbot, Codex.
A revisão de segurança do kernel envolve dois tipos distintos de incerteza.
O problema central do v1 era o primeiro: a alocação de atenção. O v2 mantém esse princípio e estende o segundo problema com a triagem ciente de proveniência. Ambas as versões foram usadas em investigações reais; a investigação assistida pelo v1 levou à CVE-2026-31720, e a assistida pelo v2, à CVE-2026-53075.
Observações fora do modelo estreitam o escopo da investigação; após a resposta do modelo, anexa-se proveniência verificável do repositório. Nenhum sinal em qualquer estágio prova uma vulnerabilidade ou novidade.
O Sinal Externo pré-inferência não é um julgamento do LLM, mas uma observação calculada antes da execução do modelo.
Usando a mesma árvore de fontes, perfil e JSON do syzbot em cache, a classificação dos candidatos pode ser recalculada. Essa pontuação não é probabilidade ou explorabilidade, mas uma ordem relativa para decidir por onde começar.
O estágio pós-inferência combina veredictos fortes do modelo com as seguintes informações.
Neste documento, Sinal Externo pós-inferência refere-se apenas à proveniência coletada independentemente do modelo, como repositório/status Git, branch, HEAD, estado sujo e ancestralidade de commits locais. CVEs, commits e marcadores conhecidos são referências derivadas do modelo extraídas da resposta, não Sinal Externo ou fato autoritativo. A triagem combina os dois tipos de entrada, mas registra suas origens separadamente.
Achados fortes são organizados operacionalmente em um dos seguintes buckets de revisão.
| Bucket | Significado |
|---|---|
new_candidate | Candidato com proveniência confirmada e sem sinais de bloqueio por estado sujo/conhecido |
known_issue | Candidato com referência conhecida não negada, ou commit apontado pela resposta como correção/relação upstream e confirmado como ancestral do HEAD atual |
dirty_tree_suspect | Candidato cuja influência de repositório sujo ou alvo sujo não pode ser descartada |
provenance_unknown | Candidato cujo repositório Git, status ou HEAD não pôde ser confirmado de forma confiável |
novelty_proven é false para todos os resultados de classificação. new_candidate não significa “nova vulnerabilidade”, mas sim uma fila para o humano continuar a investigação de novidade primeiro.
A auditoria verifica primeiro as fronteiras iniciadas no espaço do usuário, como syscall, ioctl, netlink, procfs, filesystem, BPF e hooks de driver. Somente depois avalia classes de bug como UAF, OOB, refcount, race, vazamento de informação e verificação de capability.
Uma unidade de investigação é limitada a um arquivo e seus callers, teardown e caminhos de free próximos. Follow-ups manuais propostos pelo modelo são limitados a no máximo dois, mantendo caminhos curtos e verificáveis em vez de exploração ampla.
Um achado forte deve explicar, no mínimo, o seguinte.
O parser normaliza apenas o veredicto e o próximo alvo; ele não prova automaticamente a completude dessas evidências.
