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.

I. Introdução

A revisão de segurança do kernel envolve dois tipos distintos de incerteza.

1. Por onde começar. A árvore de fontes inteira é grande demais para caber em um único contexto de modelo.
2. Como tratar achados fortes produzidos pelo modelo. Modificações locais, correções existentes, CVEs conhecidas ou estado incompleto do repositório podem contaminar as conclusões.

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.

II. Sinal Externo e Princípios de Design

A. Estágio 1 — Alocação de Atenção Antes da Inferência

O Sinal Externo pré-inferência não é um julgamento do LLM, mas uma observação calculada antes da execução do modelo.

• Pesos de caminhos e subsistemas do kernel
• Correspondências lexicais como usercopy, allocator, refcount, size, lock
• Sobreposição de arquivo/subsistema com o JSON do syzbot armazenado

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.

B. Estágio 2 — Triagem Ciente de Proveniência Após a Inferência

O estágio pós-inferência combina veredictos fortes do modelo com as seguintes informações.

• Se é um repositório Git e se a coleta de status foi bem-sucedida
• Branch e HEAD
• Estado sujo do repositório e do arquivo alvo
• CVEs, hashes de commit e marcadores de problema conhecido extraídos da resposta
• Expressões de negação ou referências não relacionadas presentes na resposta

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.

C. Buckets Heurísticos, Não Prova de Novidade

Achados fortes são organizados operacionalmente em um dos seguintes buckets de revisão.

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.

D. Alcançabilidade Antes da Classe de Bug

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.

E. Um Ramo de Investigação por Vez

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.

F. Evidência Acima de Confiança

Um achado forte deve explicar, no mínimo, o seguinte.

1. entrypoint alcançável pelo atacante,
2. campo controlado pelo atacante ou transição de lifetime,
3. invariante de objeto·comprimento·estado que é quebrada,
4. impacto concreto como corrupção, vazamento ou escalonamento de privilégio,
5. por que a verificação existente não impede o ataque.

O parser normaliza apenas o veredicto e o próximo alvo; ele não prova automaticamente a completude dessas evidências.

G. Linhagem de Design

O fluxo inicial partiu das ideias de análise por arquivo, expansão limitada de contexto e saída estruturada usadas pelo vulnhuntr da Protect AI [1]. Neste projeto, isso foi redesenhado para a superfície do kernel alcançável pelo espaço do usuário, lifetime de objetos do kernel, caminhos de teardown e sobreposição com syzbot. A contribuição adicional do v2 é colocar um estágio de triagem de achados usando proveniência do repositório após a alocação de atenção.

III. Arquitetura do Sistema

Fig. 1. O Sinal Externo pré-inferência classifica unidades de revisão reproduzíveis. A triagem pós-inferência combina proveniência Git independente do modelo com referências da resposta derivadas do modelo, sem tratar estas últimas como Sinal Externo ou fato autoritativo. A validação humana permanece fora de ambos os estágios automatizados.

TABELA I — RESPONSABILIDADES DOS MÓDULOS PRINCIPAIS

IV. Metodologia

A. Descoberta e Pontuação de Candidatos

O scanner percorre arquivos .c e .h sob o diretório de includes do perfil.

A implementação atual soma correspondências em nível de linha e limita apenas o número de sinais principais exibidos no prompt. A pontuação determina a ordem de investigação do modelo, mas não é uma estatística calibrada de probabilidade de vulnerabilidade.

Os principais sinais estáticos são os seguintes.

• ioctl, handlers compat, hooks de operação de arquivo
• copy_from/to_user e __user
• kmalloc/kzalloc/kvmalloc, alocação de cache e caminhos de free
• refcount, atomic, kref
• cálculos de size·length e família memcpy
• lock, RCU, lifetime assíncrono
• BPF, skb, XDP, netlink
• verificações de capability e namespace

B. Escopo Orientado por Perfil

C. Inteligência de Crash

O syzbot-fetch extrai título, subsistema, tipo de bug e file:line de páginas públicas de bugs do syzbot e os salva em JSON. Sobreposição exata de arquivo é um sinal forte de classificação; sobreposição de subsistema é um sinal fraco. O dashboard ao vivo pode mudar, então a unidade de reprodução é o JSON salvo no momento da coleta. Sobreposição de crash é uma dica para caça de variantes, não evidência de vulnerabilidade.

D. Contrato de Sessão e Revisão

O scan gera um manifest completo de candidatos classificados e um pacote de prompts principais. --limit define o número de candidatos mantidos no manifest, e --top o número de pacotes pré-gerados. Classificações posteriores podem ser geradas sob demanda.

As respostas do modelo são normalizadas para um dos seguintes veredictos.

• cve_candidate
• plausible_security_bug
• latent_bug
• not_cve_candidate
• needs_more_context

Revisão manual e autopilot usam o mesmo review_state.json, caminho fixo de resposta e parser de veredicto.

E. Coleta de Proveniência e Triagem

O doctor e o autopilot verificam se é um repositório Git, se a coleta de status foi bem-sucedida, branch, HEAD e caminhos sujos. Um estado em que a proveniência não pode ser confirmada não é tratado como limpo; é preservado como provenance_unknown.

A triagem de veredictos fortes segue aproximadamente esta prioridade.

1. Se a proveniência não for confiável, provenance_unknown,
2. Se o repositório ou alvo estiver sujo, dirty_tree_suspect,
3. Se houver CVE relacionada ou marcador não negado, ou se o commit apontado pela resposta como correção/relação upstream for ancestral do HEAD atual, known_issue,
4. Caso contrário, new_candidate.

Expressões de negação ou não relacionamento, como “not a known issue” ou “unrelated to CVE-…”, não são usadas como base para conhecido. A decisão final registra o veredicto original junto com branch, HEAD, status, estado sujo, referência correspondida e motivo.

Atualmente, a classificação em buckets cientes de proveniência e o escritor JSONL são aplicados ao caminho de ingest do autopilot. O loop e o ingest manuais usam o mesmo estado básico de sessão e parser de veredicto, mas não geram artefatos de bucket.

V. Implementação e Uso

A. Requisitos

• Python 3.11 ou superior
• Árvore de fontes do kernel Linux
• Git para uso de provenance/doctor/autopilot
• Codex CLI e autenticação para uso do autopilot [3]
• Conexão de rede para coleta remota do syzbot

As dependências de runtime do Python são apenas a biblioteca padrão.

B. Instalação

Os perfis JSON embutidos são incluídos no wheel. Regras adicionais podem ser passadas com --config /path/to/profile.json.

C. Workflow Mínimo

Respostas manuais do Codex devem ser salvas em codex_response.txt, conforme especificado no runbook, e podem ser ingeridas com o seguinte comando.

D. Autopilot com Orçamento de Tempo

O padrão do sandbox do Codex é read-only. --require-clean-tree permite a execução somente quando o repositório Git, status e HEAD são confirmados e a árvore de trabalho está limpa. --stop-on-finding interrompe somente quando o resultado da triagem heurística é new_candidate.

E. Feed Opcional do syzbot

F. Artefatos de Sessão

AUTOPILOT_FINDINGS.jsonl preserva veredicto, bucket, motivo, branch, HEAD, estado de proveniência, referência correspondida e caminhos de achado/arquivo em um formato processável.

VI. Resultado Operacional e Verificação

O v2 aplicou a estrutura estendida a uma investigação real de vulnerabilidades no kernel Linux.

TABELA II — RESULTADO DE VULNERABILIDADE DIVULGADA

Os 16 testes de regressão não são um benchmark de precisão de detecção de segurança, mas focam no contrato de software e na capacidade de distribuição.

• Regressão de recursos de allocator e perfis embutidos
• Verificação de que veredictos negativos e expressões de CVE em prosa geral não são revertidos para achados fortes
• Limite de follow-up manual e ordenação de classificação
• Arquivamento de respostas obsoletas sem alvo pendente
• Padrão de sandbox read-only e argumento CLI positivo
• Proveniência fail-closed para ausência/não-Git/falha de status
• Triagem de alvo sujo, referência conhecida, negação e CVE não relacionada
• Preservação de histórico de sessão e JSONL de metadados de classificação
• Contrato de artefatos de erro de parse e achado
• Smoke test de varredura de perfil no wheel instalado

O GitHub Actions executa testes de regressão em Python 3.11 e 3.12, instala o wheel e faz smoke-test dos 6 perfis empacotados e da varredura padrão. O caso público acima é um resultado operacional obtido em investigação real, mas não é um benchmark de precisão, recall, explorabilidade ou taxa de descoberta de CVEs medido em um corpus representativo de árvores Linux.

VII. Considerações de Segurança

• O padrão do sandbox do Codex é read-only e recomenda-se mantê-lo.
• Se proveniência limpa for importante, use doctor seguido de --require-clean-tree.
• Não interprete ausência de Git ou falha de confirmação de status/HEAD como limpo.
• --dangerously-bypass-approvals-and-sandbox não deve ser usado fora de um ambiente experimental isolado.
• Comentários de código e identificadores também são entradas do modelo; considere a possibilidade de prompt injection.
• Strings de CVE e commit são apenas referências de resposta, não confirmação autoritativa.
• Antes de divulgar ou relatar um achado, um humano deve reverificar alcançabilidade, invariante, impacto e versões afetadas.

VIII. Limitações e Ameaças à Validade

1. Análise lexical. Não constrói AST C real, grafo de chamadas ou fluxo de dados interprocedural.
2. Viés de pontuação. Comentários, macros, tokens repetidos e arquivos grandes podem influenciar excessivamente a pontuação.
3. Lacuna de alcançabilidade. Configuração do kernel, privilégio, namespace e disponibilidade de dispositivos não são modelados automaticamente.
4. Fragilidade de dados externos. A integração com syzbot é afetada por mudanças na estrutura do HTML público.
5. Apenas proveniência local. A ancestralidade Git é relativa ao HEAD do checkout atual e não representa todo o histórico upstream ou de fornecedores.
6. Referências derivadas da resposta. CVEs e marcadores conhecidos são extraídos da resposta do modelo, portanto há risco de omissão, alucinação ou má interpretação de contexto.
7. Triagem heurística. Tanto new_candidate quanto known_issue não são determinações finais de novidade.
8. Dependência do modelo. A qualidade dos resultados depende do modelo, da interpretação do prompt e do contexto disponível do repositório.
9. Escopo da avaliação. Os testes atuais verificam regressão de software. O caso de CVE divulgado é um resultado de uso real, mas não substitui uma avaliação estatística do desempenho de detecção de segurança.

IX. Evolução e Retrospectiva

O v1 (repositório) focou no problema de alocar atenção do LLM com Sinal Externo e foi usado em uma investigação real assistida pelo v1 que descobriu a CVE-2026-31720. O v2 dá continuidade à mesma filosofia de pesquisa e a estende para registrar o estado do repositório e referências derivadas da resposta mesmo após o modelo produzir um achado forte. Uma investigação subsequente usando essa estrutura descobriu a CVE-2026-53075.

Dois princípios devem ser mantidos nessa evolução.

1. Não interpretar a pontuação pré-inferência como prova de vulnerabilidade.
2. Não interpretar o bucket pós-inferência como prova de novidade.

Se fosse estendido novamente, priorizaria grafo de chamadas Clang/tree-sitter, normalização de pontuação, manifest versionado com bloqueio de estado entre processos, adaptador de banco de dados autoritativo de CVE/correção e separação de runner·triagem·escritor de artefatos. A escrita de estado atual usa arquivo temporário e substituição atômica.

X. Conclusão

O Kernel Codex Harness v2 não substitui a detecção de vulnerabilidades. Antes da chamada do modelo, o Sinal Externo aloca o orçamento de investigação para candidatos explicáveis; após a chamada, o sinal de proveniência organiza achados fortes em filas revisáveis. Essa estrutura foi usada em uma investigação real que descobriu a CVE-2026-53075, e o principal resultado do projeto não é um algoritmo de determinação automática de novidade, mas sim um workflow prático de revisão de segurança com LLM que separa explicitamente alocação de atenção e triagem ciente de proveniência.

Apêndice A. Estrutura do Repositório

Operação manual detalhada pode ser consultada no guia do Codex CLI, execução automática e triagem no guia do Autopilot e inteligência de crash no guia do syzbot.

Referências

[1] Protect AI, “vulnhuntr,” repositório GitHub. https://github.com/protectai/vulnhuntr

[2] Google, “syzkaller and syzbot,” repositório GitHub. https://github.com/google/syzkaller

[3] OpenAI, “Codex CLI.” https://developers.openai.com/codex/cli/

Licença

Licenciado sob a Apache License 2.0.