Termos de Índice— kernel Linux, pesquisa de vulnerabilidades, sinal externo, orquestração de LLM, priorização heurística, syzbot, análise de programas, Codex.

I. Introdução

A revisão de segurança do kernel Linux enfrenta dois tipos de problemas de escala. Primeiro, a árvore de fontes completa é grande demais para caber em um único contexto de LLM. Segundo, sinais como copy_from_user, alocadores, refcount e locks são comuns, mas não significam vulnerabilidades por si só. O analista deve primeiro decidir "onde olhar" e, em seguida, provar separadamente a reachability de userspace e as transições de estado concretas.

A filosofia central deste projeto é o Sinal Externo.

Não deixamos o LLM decidir sozinho onde olhar. Sinais reproduzíveis fora da inferência do modelo alocam a atenção, mas as conclusões sobre vulnerabilidades são determinadas apenas por evidências de reachability e invariantes.

Portanto, o harness não faz o modelo explorar vagamente o kernel inteiro. Ele prioriza arquivos, fornece apenas um ramo de investigação por vez e exige estrutura de evidências antes de conclusões.

II. Sinal Externo e Princípios de Design

A. Sinal Externo Antes da Inferência do Modelo

Sinal Externo não é um julgamento gerado pelo LLM; é uma observação determinada antes da execução do modelo e recalculável a partir da mesma árvore de fontes, perfil e JSON do syzbot armazenado. Pesos de caminho, hits de regex e sobreposição com syzbot em cache se enquadram nisso. Esses sinais são usados apenas para ranquear candidatos e fornecer contexto de prompt; nunca são promovidos a veredito ou prova.

Neste documento, Sinal Externo refere-se à filosofia geral do projeto. O modelo de dados ExternalSignal no código atualmente representa apenas os sinais derivados do syzbot, portanto o escopo dos dois termos é diferente.

B. Priorização Não É Prova

Hits de regex, caminhos de alto risco e sobreposição com syzbot são todos sinais para ordenar a investigação. Uma pontuação alta não constitui um achado de segurança se o caminho de chamada real, privilégios, config do kernel, namespace ou disponibilidade de dispositivo não permitirem o alcance do atacante.

C. Reachability Antes da Classe de Bug

A auditoria primeiro verifica as fronteiras iniciadas em userspace, 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ções de capability.

D. Um Ramo de Investigação por Vez

Uma unidade de investigação é limitada, por padrão, a um arquivo e seus callers, teardown e caminhos de free próximos. Follow-ups manuais recomendados pelo modelo são permitidos no máximo duas vezes. Essa limitação não visa reduzir a capacidade de exploração, mas manter as conclusões dentro de um escopo verificável.

E. Evidência Acima de Confiança

O prompt exige que um achado forte explique pelo menos os seguintes itens:

1. entrypoint alcançável pelo atacante,
2. campo controlado pelo atacante ou transição de lifetime,
3. invariante de objeto, comprimento ou estado que é quebrada,
4. impacto concreto, como corrupção, vazamento ou escalonamento de privilégios,
5. por que as verificações existentes não impedem o ataque.

Se a evidência for insuficiente, o modelo retorna um único alvo para verificação em seguida, em vez de afirmar fortemente uma vulnerabilidade. Este é um contrato de evidência em nível de prompt; o parser atual não valida automaticamente a completude de cada evidência. Como a ingestão normaliza o veredito e o próximo alvo, a validação final da evidência é responsabilidade humana.

F. Linhagem de Design

O fluxo inicial de investigação partiu das ideias de análise por arquivo, expansão limitada de contexto e saídas estruturadas usadas pelo vulnhuntr da Protect AI [1]. Neste projeto, essas ideias não foram aplicadas diretamente à análise de aplicações Python, mas redesenhadas em torno da superfície do kernel alcançável por userspace, do lifetime de objetos do kernel, dos caminhos de teardown e da sobreposição com syzbot. Em particular, separar sinais de priorização da prova de vulnerabilidade e verificar reachability antes da classe de bug são as escolhas centrais de design do harness para kernel.

III. Arquitetura do Sistema

Fig. 1. A camada de Sinal Externo transforma observações calculadas antes da inferência do modelo em unidades de revisão ranqueadas. Ela aloca atenção, mas não estabelece prova de vulnerabilidade.

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 pontuação de prioridade do arquivo f é conceitualmente composta da seguinte forma:

Essa pontuação não é uma medida de probabilidade ou explorabilidade. Cada item fornece apenas uma ordem relativa para o modelo decidir quais arquivos verificar primeiro. A implementação atual soma todas as correspondências em nível de linha e limita apenas os principais sinais exibidos no prompt. O recálculo do mesmo resultado pressupõe a mesma árvore de fontes, perfil e JSON do syzbot em cache. O peso do syzbot é aplicado posteriormente a arquivos que já se tornaram candidatos pelas heurísticas de caminho e linha; um hit do syzbot sozinho não gera novos arquivos candidatos.

Os principais sinais estáticos incluem:

• ioctl, handlers compat, hooks de operações de arquivo
• copy_from_user, copy_to_user, __user
• kmalloc, kzalloc, kvmalloc, alocação de cache e caminhos de free
• operações de refcount, atomic e kref
• cálculos de tamanho/comprimento e famílias de memcpy
• padrões de lock, RCU e lifetime assíncrono
• fronteiras de BPF, skb, XDP e netlink
• verificações de capability e namespace

B. Escopo Orientado por Perfil

Os perfis integrados são default, net, fs, io_uring, bpf e drivers. Cada perfil define caminhos de include, padrões, pesos e o número de sinais preservados por arquivo. Em vez de aplicar uma única política de pontuação a todo o kernel, os perfis refletem a superfície de ataque e as características de lifetime de cada subsistema.

C. Inteligência de Crashes

O syzbot-fetch extrai título, subsistema, tipo de bug e informações de arquivo:linha das páginas públicas de bugs do syzbot do projeto syzkaller [2] e as armazena em um cache JSON. A sobreposição exata de arquivo é um Sinal Externo forte; a sobreposição de subsistema é um Sinal Externo fraco. Como o dashboard ao vivo pode mudar, a unidade de reprodução é o JSON armazenado no momento da coleta. As informações de crash são apenas um ponto de partida para a caça de variantes, não evidência de novas vulnerabilidades.

D. Sessão e Contrato de Revisão

O scan gera um manifest de candidatos ranqueados e os principais pacotes de prompt. Cada prompt inclui o caminho do alvo, o motivo da pontuação, sinais de linha, contexto do syzbot e o procedimento de auditoria.

A resposta do modelo é normalizada para um dos seguintes vereditos:

• cve_candidate
• plausible_security_bug
• latent_bug
• not_cve_candidate
• needs_more_context

A resposta inclui um único Single best next target e um breve resumo. Respostas antigas sem alvo pendente são arquivadas separadamente e não são vinculadas a novos alvos.

V. Implementação e Uso

A. Requisitos

• Python 3.11 ou superior
• Codex CLI [3] e autenticação ao usar o autopilot
• Conexão de rede para coleta remota do dashboard do syzbot

B. Instalação

Os JSONs de perfil integrados são incluídos no wheel. Regras JSON externas podem ser passadas com --config /path/to/profile.json.

C. Workflow Mínimo

--limit define o número de candidatos mantidos no manifest; --top define o número de pacotes de prompt pré-gerados inicialmente. Pacotes de ranks posteriores também podem ser gerados sob demanda.

D. Autopilot com Orçamento de Tempo

O sandbox padrão é read-only. Use --sandbox workspace-write somente se a modificação de arquivos for estritamente necessária durante a análise.

E. Feed Opcional do syzbot

F. Artefatos da Sessão

VI. Resultado Operacional e Verificação

Esta versão não permaneceu apenas como prova de conceito; foi usada em uma investigação real de vulnerabilidades no kernel Linux.

TABELA II — RESULTADO DE VULNERABILIDADE DIVULGADA

A verificação não é um benchmark de precisão de detecção, mas sim um foco em regressões de implementação e capacidade de implantação.

TABELA III — ESCOPO DE VERIFICAÇÃO DE ENGENHARIA

O GitHub Actions executa regressões unitárias, instala o wheel em um novo ambiente e faz smoke-test do scan com o perfil default. O caso divulgado acima é um resultado operacional obtido em investigação real, mas não é um benchmark de precisão, recall ou taxa de descoberta de CVEs medido em um corpus representativo de árvores Linux.

VII. Considerações de Segurança

• Recomenda-se manter o sandbox padrão read-only.
• Não use --dangerously-bypass-approvals-and-sandbox em ambientes sem sandbox externo.
• Comentários e identificadores de fontes não confiáveis também podem ser entradas do modelo; considere a possibilidade de prompt injection.
• Achados gerados pelo modelo devem ser revalidados por humanos quanto a reachability e impacto antes de divulgação ou relatório.
• Crashes do syzbot e pontuações heurísticas altas não devem ser citados como prova de vulnerabilidade.

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

1. Análise lexical. Não constrói AST real de C, 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 reachability. Config do kernel, privilégios, namespace e disponibilidade de dispositivo 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. Dependência do modelo. A qualidade dos resultados depende do modelo usado, da interpretação do prompt e do contexto do repositório.
6. Escopo da avaliação. Os testes atuais verificam regressões de software. O caso 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. Retrospectiva

Desde a primeira versão registrada no histórico do Git, o objetivo esteve mais próximo de "controlar qual código revisar primeiro e quais evidências exigir" do que de "fazer o LLM encontrar vulnerabilidades sozinho". A investigação assistida pela v1 que descobriu o CVE-2026-31720 forneceu um caso de aplicação real da unidade de investigação estreita e do contrato de evidências. A v2 estendeu esse workflow para triagem ciente de proveniência, preservando o estado do repositório e referências conhecidas. Se eu fosse reimplementar agora, priorizaria:

1. grafo de símbolos/chamadas baseado em tree-sitter ou Clang,
2. normalização de pontuação considerando tamanho do arquivo e hits repetidos,
3. separação das camadas review e runner para eliminar duplicação entre CLI e autopilot,
4. manifest versionado e escrita atômica de estado,
5. respostas do modelo e evidências estruturadas baseadas em JSON Schema,
6. vinculação automática de crashes do syzbot, commits de correção e variantes próximas.

Ainda assim, o princípio central que quero manter é o Sinal Externo. Não deixar o LLM explorar vagamente toda a base de código; em vez disso, repetir unidades de investigação estreitas, guiadas por sinais externos ao modelo, com foco em reachability e invariantes.

X. Conclusão

O Kernel Codex Harness não substitui a detecção de vulnerabilidades no kernel Linux. Em vez disso, transforma o Sinal Externo em um ranqueamento explicável e limita a revisão do LLM a um processo de investigação curto e com estado. Essa estrutura foi usada em investigação real para descobrir o CVE-2026-31720. O principal resultado do projeto não está em reivindicar um novo algoritmo de análise, mas em definir a revisão de segurança com LLM como um problema de alocação de atenção por sinal externo, contrato de evidências e orquestração reproduzível, aplicado a um workflow de pesquisa real.

Apêndice A. Estrutura do Repositório

Procedimentos operacionais detalhados podem ser encontrados em docs/.

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.