Index Terms— Linux kernel, vulnerability research, external signal, LLM orchestration, heuristic prioritization, syzbot, program analysis, Codex.

I. Introduction

При проверке безопасности ядра Linux существуют два вида проблем масштаба. Во-первых, всё дерево исходников слишком велико, чтобы уместиться в один контекст LLM. Во-вторых, такие сигналы, как copy_from_user, аллокаторы, refcount и блокировки, распространены, но сами по себе не означают уязвимость. Аналитик должен сначала решить, «куда смотреть», а затем отдельно доказать достижимость из userspace и конкретные переходы состояний.

Ключевая философия этого проекта — External Signal.

Мы не позволяем LLM самому решать, куда смотреть. Воспроизводимые сигналы вне логического вывода модели распределяют внимание, но вывод об уязвимости делается только на основе reachability и evidence об инвариантах.

Поэтому harness не заставляет модель бесцельно исследовать всё ядро. Он приоритизирует файлы, предоставляет только одну ветвь исследования за раз и требует сначала структуру доказательств, а не выводы.

II. External Signal and Design Principles

A. External Signal Before Model Inference

External Signal — это не суждение, сгенерированное LLM, а наблюдение, которое определяется до выполнения модели и может быть пересчитано на основе того же дерева исходников, профиля и сохранённого syzbot JSON. Сюда относятся веса путей, совпадения регулярных выражений и кэшированное пересечение с syzbot. Эти сигналы используются только для ранжирования кандидатов и контекста промптов и не повышаются до вердикта или доказательства.

External Signal в этом документе относится ко всей философии проекта. Модель данных ExternalSignal в коде в настоящее время представляет только те сигналы, которые происходят из syzbot, поэтому объёмы этих двух терминов различаются.

B. Prioritization Is Not Proof

Совпадения регулярных выражений, пути высокого риска и пересечения с syzbot — всё это сигналы для порядка исследования. Даже высокий балл не является security finding, если реальный путь вызова, привилегии, конфигурация ядра, namespace или доступность устройства не позволяют атакующему достичь цели.

C. Reachability Before Bug Class

Аудит сначала проверяет границы, начинающиеся из userspace: syscall, ioctl, netlink, procfs, файловые системы, BPF, хуки драйверов. Только после этого оцениваются классы ошибок: UAF, OOB, refcount, race, утечка информации, проверки capability.

D. One Investigation Branch at a Time

Одна единица исследования по умолчанию ограничена одним файлом и ближайшими путями caller, teardown и free. Ручные follow-up, рекомендованные моделью, разрешены максимум дважды. Это ограничение введено не для уменьшения исследовательских возможностей, а для сохранения выводов в проверяемых рамках.

E. Evidence Over Confidence

Промпт требует, чтобы сильная находка как минимум описывала следующие пункты.

1. entrypoint, достижимый атакующим,
2. поле, контролируемое атакующим, или переход lifetime,
3. нарушаемый инвариант объекта, длины или состояния,
4. конкретное воздействие: corruption, утечка, повышение привилегий и т. д.,
5. причина, по которой существующая проверка не предотвращает атаку.

Если доказательств недостаточно, модель вместо сильного утверждения об уязвимости возвращает единственную цель для следующей проверки. Это prompt-level evidence contract; текущий парсер не проверяет автоматически полноту каждого доказательства. Поскольку ingestion нормализует вердикт и следующую цель, окончательная проверка доказательств — ответственность человека.

F. Design Lineage

Ранний поток исследования исходил из идей файлового анализа, ограниченного расширения контекста и структурированных результатов, использованных в vulnhuntr от Protect AI [1]. В этом проекте эти идеи не применяются напрямую к анализу Python-приложений, а переработаны вокруг достижимой из userspace поверхности ядра, lifetime объектов ядра, путей teardown и пересечений с syzbot. В частности, разделение сигналов приоритизации и доказательства уязвимости, а также проверка reachability до класса ошибки — ключевые проектные решения harness'а для ядра.

III. System Architecture

Fig. 1. The External Signal layer turns observations computed before model inference into ranked review units. It allocates attention but does not establish vulnerability proof.

TABLE I — MAJOR MODULE RESPONSIBILITIES

IV. Methodology

A. Candidate Discovery and Scoring

Сканер обходит файлы .c и .h в каталогах include из профиля. Балл приоритета файла f концептуально состоит из следующих частей.

Этот балл не является мерой вероятности или эксплуатируемости. Каждый компонент даёт только относительный порядок для определения того, какие файлы модель должна проверить в первую очередь. Текущая реализация суммирует все совпадения на уровне строк и ограничивает только верхние сигналы, отображаемые в промпте. Пересчёт того же результата предполагает то же дерево исходников, профиль и кэшированный syzbot JSON. Вес syzbot применяется постфактум к файлам, которые уже стали кандидатами с помощью эвристик путей и строк; только совпадение с syzbot не создаёт новый файл-кандидат.

Основные статические сигналы:

• ioctl, compat handler, хуки file operation
• copy_from_user, copy_to_user, __user
• kmalloc, kzalloc, kvmalloc, аллокации кэша и пути free
• операции refcount, atomic, kref
• вычисления размера/длины и семейство memcpy
• паттерны lock, RCU, асинхронного lifetime
• границы BPF, skb, XDP, netlink
• проверки capability и namespace

B. Profile-Driven Scope

Встроенные профили: default, net, fs, io_uring, bpf, drivers. Профиль определяет include path, паттерны, веса и количество сигналов, сохраняемых для одного файла. Вместо применения единой политики оценки ко всему ядру профили отражают поверхность атаки и особенности lifetime каждой подсистемы.

C. Crash Intelligence

syzbot-fetch извлекает из публичных страниц ошибок syzbot проекта syzkaller [2] заголовок, подсистему, тип ошибки и информацию file:line и сохраняет их в JSON-кэш. Точное пересечение файлов — сильный External Signal, пересечение подсистем — слабый External Signal. Поскольку живая панель может меняться, единицей воспроизводимости является сохранённый JSON на момент выборки. Информация о сбоях — это только отправная точка для поиска вариантов, а не доказательство новой уязвимости.

D. Session and Review Contract

scan создаёт ранжированный manifest кандидатов и пакеты верхних промптов. Каждый промпт включает путь цели, причину балла, строчные сигналы, контекст syzbot и процедуру аудита.

Ответ модели нормализуется до одного из следующих вердиктов.

• cve_candidate
• plausible_security_bug
• latent_bug
• not_cve_candidate
• needs_more_context

Ответ содержит один Single best next target и краткое резюме. Устаревшие ответы без ожидающей цели не связываются с новой целью, а архивируются отдельно.

V. Implementation and Usage

A. Requirements

• Python 3.11 или новее
• Codex CLI [3] и аутентификация при использовании autopilot
• Сетевое подключение для сбора удалённой панели syzbot

B. Installation

Встроенные JSON-профили включены в wheel. Внешние JSON-правила можно передать через --config /path/to/profile.json.

C. Minimal Workflow

--limit — количество кандидатов, сохраняемых в manifest; --top — количество пакетов промптов, создаваемых заранее. Пакеты для последующих рангов также можно создавать по запросу.

D. Time-Budgeted Autopilot

Песочница по умолчанию — read-only. --sandbox workspace-write следует указывать только в тех случаях, когда изменение файлов в процессе анализа действительно необходимо.

E. Optional syzbot Feed

F. Session Artifacts

VI. Operational Outcome and Verification

Эта версия не осталась на уровне концептуального доказательства, а использовалась в реальном исследовании уязвимостей ядра Linux.

TABLE II — DISCLOSED VULNERABILITY OUTCOME

Проверка фокусируется не на бенчмарке точности обнаружения, а на регрессиях реализации и возможности развёртывания.

TABLE III — ENGINEERING VERIFICATION SCOPE

GitHub Actions выполняет модульные регрессионные тесты, затем устанавливает wheel в новое окружение и проводит smoke-test сканирования с профилем default. Приведённый выше публичный случай — это операционный результат реального исследования, а не бенчмарк precision, recall или скорости обнаружения CVE, измеренный на репрезентативном корпусе деревьев Linux.

VII. Safety Considerations

• Рекомендуется сохранять песочницу read-only по умолчанию.
• В средах без внешней песочницы не используйте --dangerously-bypass-approvals-and-sandbox.
• Ненадёжные комментарии и идентификаторы в исходниках также могут стать входными данными модели, поэтому следует учитывать prompt injection.
• Находки, сгенерированные моделью, должны быть повторно проверены человеком на reachability и воздействие до публикации или отчётности.
• Сбои syzbot и высокие эвристические баллы нельзя цитировать как доказательство уязвимости.

VIII. Limitations and Threats to Validity

1. Lexical analysis. Не строится реальный C AST, call graph или межпроцедурный поток данных.
2. Score bias. Комментарии, макросы, повторяющиеся токены и большие файлы могут непропорционально влиять на балл.
3. Reachability gap. Конфигурация ядра, привилегии, namespace и доступность устройств не моделируются автоматически.
4. External data fragility. Интеграция syzbot зависит от изменений структуры публичного HTML.
5. Model dependence. Качество результатов зависит от используемой модели, интерпретации промптов и контекста репозитория.
6. Evaluation scope. Текущие тесты проверяют программные регрессии. Публичный случай CVE — это результат реального использования, но он не заменяет статистическую оценку эффективности обнаружения.

IX. Retrospective

С самой первой версии, зафиксированной в истории Git, цель была ближе к «контролю над тем, какой код смотреть первым и какие доказательства требовать», чем к «позволить LLM самому находить уязвимости». Исследование с поддержкой v1, обнаружившее CVE-2026-31720, дало пример применения узких единиц исследования и контракта доказательств в реальной работе. v2 расширяет этот workflow до provenance-aware triage, сохраняющего состояние репозитория и известные reference. Если бы я реализовывал это сейчас, я бы в первую очередь сделал следующее.

1. symbol/call graph на основе tree-sitter или Clang,
2. нормализацию баллов с учётом размера файла и повторяющихся совпадений,
3. разделение слоёв review и runner для устранения дублирования CLI/autopilot,
4. versioned manifest и атомарную запись состояния,
5. ответы модели и структурированные доказательства на основе JSON Schema,
6. автоматическую связь сбоев syzbot, fix commit и близких вариантов.

Тем не менее центральный принцип, который я хочу сохранить, — это External Signal. Не заставлять LLM бесцельно исследовать всю кодовую базу, а повторять суженные внешними сигналами единицы исследования с фокусом на reachability и инварианты.

X. Conclusion

Kernel Codex Harness не заменяет обнаружение уязвимостей в ядре Linux. Вместо этого он превращает External Signal в объяснимый рейтинг и ограничивает проверку LLM короткими, сохраняющими состояние исследовательскими процессами. Эта структура использовалась в реальном исследовании для обнаружения CVE-2026-31720. Ключевой результат проекта — не в утверждении нового алгоритма анализа, а в определении LLM-проверки безопасности как задачи external-signal attention allocation, evidence contract, reproducible orchestration и применении этого определения в реальном исследовательском workflow.

Appendix A. Repository Layout

Подробные операционные процедуры можно найти в docs/.

References

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

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

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

License

Licensed under the Apache License 2.0.