Аннотация — Если позволить LLM напрямую исследовать такую большую кодовую базу, как ядро Linux, контекст распыляется, а наличие опасных API легко спутать с реальной эксплуатируемостью. Kernel Codex Harness v2 определяет эту проблему как обработку двухэтапного внешнего сигнала. До вызова модели весовые коэффициенты путей, лексические совпадения и кэшированное пересечение с syzbot ранжируют файлы-кандидаты для распределения внимания. После ответа модели Git-ветка, HEAD, состояние dirty и извлечённые из ответа CVE, commit и известные маркеры объединяются для классификации сильных находок в корзины проверки с учётом происхождения. Этот харнес использовался в реальном исследовании ядра Linux и обнаружил дефект проверки прав доступа к целевому сетевому пространству имён PPP, который был опубликован как CVE-2026-53075. Триаж — это эвристика для упорядочивания очереди исследования; в частности, new_candidate означает лишь то, что не было обнаружено известных подсказок или проблем с происхождением, а не доказательство новизны. Все находки требуют повторной проверки человеком на достижимость из userspace, нарушение инвариантов и конкретное воздействие.

Ключевые термины — ядро Linux, исследование уязвимостей, внешний сигнал, происхождение, эвристический триаж, оркестрация LLM, syzbot, Codex.

I. Введение

При проверке безопасности ядра существует два различных типа неопределённости.

1. С чего начать. Всё дерево исходников слишком велико для одного контекста модели.
2. Как обрабатывать сильные находки модели. Локальные модификации, существующие исправления, известные CVE или неполное состояние репозитория могут исказить выводы.

Центральной проблемой v1 была первая — распределение внимания. v2 сохраняет этот принцип и расширяет его до триажа с учётом происхождения для второй проблемы. Обе версии использовались в реальных исследованиях: исследование с поддержкой v1 привело к CVE-2026-31720, а исследование с поддержкой v2 — к CVE-2026-53075.

Наблюдения вне модели сужают область исследования, а после ответа модели добавляется проверяемое происхождение репозитория. Ни один из сигналов на любом этапе не доказывает уязвимость или новизну.

II. Внешний сигнал и принципы проектирования

A. Этап 1 — Распределение внимания до вывода

Внешний сигнал до вывода — это не суждение LLM, а наблюдения, вычисляемые до запуска модели.

• Весовые коэффициенты путей и подсистем ядра
• Лексические совпадения: usercopy, allocator, refcount, size, lock и т. д.
• Пересечение file/subsystem с сохранённым JSON syzbot

При использовании одного и того же дерева исходников, профиля и кэшированного JSON syzbot ранжирование кандидатов можно пересчитать. Эта оценка — не вероятность и не эксплуатируемость, а относительный порядок того, что смотреть первым.

B. Этап 2 — Триаж с учётом происхождения после вывода

Пост-выводный этап объединяет сильный вердикт модели со следующей информацией.

• Является ли каталог Git-репозиторием и успешно ли собрано состояние
• Ветка и HEAD
• Состояние dirty репозитория и целевого файла
• CVE, хэши commit и маркеры известных проблем, извлечённые из ответа
• Выражения отрицания или ссылки на несвязанные темы в ответе

В этом документе пост-выводный внешний сигнал относится только к происхождению, собранному независимо от модели: Git-репозиторий/состояние, ветка, HEAD, состояние dirty, локальная родословная commit. CVE, commit и известные маркеры — это ссылки, полученные из модели, извлечённые из ответа модели, а не внешний сигнал или авторитетный факт. Триаж объединяет оба типа входных данных, но фиксирует их источники раздельно.

C. Эвристические корзины, а не доказательство новизны

Сильные находки операционно распределяются по следующим корзинам проверки.

Для всех результатов классификации novelty_proven равно false. new_candidate означает не «новая уязвимость», а очередь для приоритетного продолжения исследования новизны человеком.

D. Достижимость до класса ошибки

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

E. Одна ветвь исследования за раз

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

F. Доказательства важнее уверенности

Сильная находка должна как минимум описывать следующее.

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

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

G. Происхождение дизайна

Первоначальный поток основан на идеях пофайлового анализа, ограниченного расширения контекста и структурированных результатов, использованных в vulnhuntr от Protect AI [1]. В этом проекте они переработаны под достижимую из userspace поверхность ядра, время жизни объектов ядра, пути teardown и пересечение с syzbot. Дополнительный вклад v2 — этап триажа находок с использованием происхождения репозитория после распределения внимания.

III. Архитектура системы

Рис. 1. Внешний сигнал до вывода ранжирует воспроизводимые единицы проверки. Пост-выводный триаж объединяет независимое от модели происхождение Git со ссылками из ответа модели, не рассматривая последние как внешний сигнал или авторитетный факт. Проверка человеком остаётся вне обоих автоматизированных этапов.

ТАБЛИЦА I — ОТВЕТСТВЕННОСТЬ ОСНОВНЫХ МОДУЛЕЙ

IV. Методология

A. Обнаружение и оценка кандидатов

Сканер обходит файлы .c и .h в каталогах include профиля.

Текущая реализация суммирует совпадения на уровне строк и ограничивает лишь количество верхних сигналов, отображаемых в промпте. Оценка определяет порядок исследования модели, но не является статистической величиной, скорректированной на вероятность уязвимости.

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

• ioctl, compat-обработчики, хуки file operation
• copy_from/to_user и __user
• kmalloc/kzalloc/kvmalloc, выделение кэша и пути free
• refcount, atomic, kref
• вычисления size·length и семейство memcpy
• lock, RCU, асинхронное время жизни
• BPF, skb, XDP, netlink
• проверки capability и namespace

B. Область, управляемая профилем

C. Информация о сбоях

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

D. Контракт сессии и проверки

scan создаёт полный ранжированный manifest кандидатов и пакет верхних промптов. --limit — это количество кандидатов, сохраняемых в manifest, а --top — количество пакетов, создаваемых заранее. Остальные ранги можно создавать по запросу.

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

• cve_candidate
• plausible_security_bug
• latent_bug
• not_cve_candidate
• needs_more_context

Ручная проверка и autopilot используют один и тот же review_state.json, фиксированный путь ответа и парсер вердиктов.

E. Сбор происхождения и триаж

doctor и autopilot проверяют, является ли каталог Git-репозиторием, успешно ли собрано состояние, а также ветку, HEAD и dirty-пути. Состояние, в котором происхождение не может быть установлено, не считается чистым, а сохраняется как provenance_unknown.

Триаж сильного вердикта примерно следует следующему приоритету.

1. если происхождение ненадёжно — provenance_unknown,
2. если репозиторий или цель dirty — dirty_tree_suspect,
3. если есть связанный CVE или неотрицаемый маркер, или commit, который ответ относит к fix/upstream, является предком текущего HEAD — known_issue,
4. в противном случае — new_candidate.

Выражения отрицания или несвязанности, такие как «not a known issue», «unrelated to CVE-…», не используются как основание для known. В окончательном решении сохраняются исходный вердикт вместе с веткой, HEAD, состоянием, dirty-состоянием, совпавшей ссылкой и причиной.

Текущая классификация по корзинам с учётом происхождения и JSONL-запись применяются в пути ingest autopilot. Ручные loop и ingest используют то же базовое состояние сессии и парсер вердиктов, но не создают артефакты корзин.

V. Реализация и использование

A. Требования

• Python 3.11 или новее
• Дерево исходников ядра Linux
• Git для использования provenance/doctor/autopilot
• Codex CLI и аутентификация для autopilot [3]
• Сетевое подключение для удалённого сбора syzbot

Зависимости среды выполнения Python — только стандартная библиотека.

B. Установка

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

C. Минимальный workflow

Ручной ответ Codex сохраняется в codex_response.txt, как указано в runbook, после чего его можно ingest следующей командой.

D. Autopilot с бюджетом времени

Песочница Codex по умолчанию — read-only. --require-clean-tree разрешает выполнение только если Git-репозиторий, состояние и HEAD подтверждены, а рабочее дерево чистое. --stop-on-finding останавливается только когда результат эвристического триажа — new_candidate.

E. Необязательный поток syzbot

F. Артефакты сессии

AUTOPILOT_FINDINGS.jsonl сохраняет вердикт, корзину, причину, ветку, HEAD, состояние происхождения, совпавшую ссылку и пути находки/архива в форме, пригодной для постобработки.

VI. Операционный результат и проверка

v2 применил расширенную архитектуру к реальному исследованию уязвимостей ядра Linux.

ТАБЛИЦА II — ОПУБЛИКОВАННЫЙ РЕЗУЛЬТАТ ПО УЯЗВИМОСТИ

16 регрессионных тестов сосредоточены не на точности обнаружения безопасности, а на программном контракте и развёртываемости.

• регрессии ресурсов аллокатора и встроенных профилей
• отрицательные вердикты и выражения CVE в обычной прозе не превращаются в сильные находки
• ограничение ручных follow-up и порядок ранжирования
• архивирование устаревших ответов без ожидающих целей
• песочница read-only по умолчанию и положительные аргументы CLI
• fail-closed происхождение при отсутствии/non-Git/сбое состояния
• триаж dirty-цели, известной ссылки, отрицания и несвязанного CVE
• сохранение истории сессии и JSONL метаданных классификации
• контракт артефактов parse-error и находок
• smoke-тест сканирования профиля из установленного wheel

GitHub Actions запускает регрессионные тесты на Python 3.11 и 3.12, устанавливает wheel и выполняет smoke-тест 6 упакованных профилей и сканирования по умолчанию. Приведённый выше публичный случай — это операционный результат реального исследования, а не benchmark точности, полноты, эксплуатируемости или скорости обнаружения CVE, измеренный на репрезентативном корпусе деревьев Linux.

VII. Соображения безопасности

• Песочница Codex по умолчанию — read-only, и её рекомендуется сохранять.
• Если важно чистое происхождение, используйте doctor, затем --require-clean-tree.
• Не интерпретируйте non-Git или сбой подтверждения состояния/HEAD как чистое состояние.
• --dangerously-bypass-approvals-and-sandbox не следует использовать вне изолированной экспериментальной среды.
• Комментарии и идентификаторы исходного кода также являются входными данными модели, поэтому учитывайте возможность prompt injection.
• Строки CVE и commit — это лишь ссылки из ответа, а не авторитетное подтверждение.
• Перед раскрытием или отчётом о находке человек должен повторно проверить достижимость, инварианты, воздействие и затронутые версии.

VIII. Ограничения и угрозы валидности

1. Лексический анализ. Не строится реальное C AST, граф вызовов или межпроцедурный поток данных.
2. Смещение оценки. Комментарии, макросы, повторяющиеся токены и большие файлы могут непропорционально влиять на оценку.
3. Разрыв достижимости. Конфигурация ядра, привилегии, namespace и доступность устройств не моделируются автоматически.
4. Хрупкость внешних данных. Интеграция syzbot зависит от изменений структуры публичного HTML.
5. Только локальное происхождение. Родословная Git основана на HEAD текущего checkout и не отражает всю историю upstream и вендора.
6. Ссылки из ответа. CVE и известные маркеры извлекаются из ответа модели, поэтому возможны пропуски, галлюцинации и неверное понимание контекста.
7. Эвристический триаж. Ни new_candidate, ни known_issue не являются окончательным определением новизны.
8. Зависимость от модели. Качество результатов зависит от модели, интерпретации промпта и доступного контекста репозитория.
9. Область оценки. Текущие тесты проверяют программные регрессии. Опубликованный случай CVE — это результат реального использования, но он не заменяет статистическую оценку производительности обнаружения безопасности.

IX. Эволюция и ретроспектива

v1 (репозиторий) был сосредоточен на распределении внимания LLM с помощью внешнего сигнала и использовался в реальном исследовании с поддержкой v1, которое привело к обнаружению CVE-2026-31720. v2 продолжает ту же исследовательскую философию и расширяет её так, чтобы после сильной находки модели также фиксировались состояние репозитория и ссылки из ответа. В последующем исследовании с использованием этой архитектуры был обнаружен CVE-2026-53075.

В этой эволюции необходимо сохранить два принципа.

1. Не путать оценку до вывода с доказательством уязвимости.
2. Не путать корзину после вывода с доказательством новизны.

Если бы расширение проводилось сейчас, приоритетами были бы граф вызовов Clang/tree-sitter, нормализация оценок, версионированный manifest и межпроцессная блокировка состояния, адаптер авторитетной базы CVE/исправлений, а также разделение runner, triage и записи артефактов. Текущая запись состояния использует временные файлы и атомарную замену.

X. Заключение

Kernel Codex Harness v2 не заменяет обнаружение уязвимостей. Внешний сигнал до вызова модели распределяет исследовательский бюджет по объяснимым кандидатам, а сигнал происхождения после вызова модели организует сильные находки в проверяемые очереди. Эта архитектура использовалась в реальном исследовании для обнаружения CVE-2026-53075, и ключевой результат проекта — не алгоритм автоматического определения новизны, а боевой workflow проверки безопасности с LLM, явно разделяющий распределение внимания и триаж с учётом происхождения.

Приложение A. Структура репозитория

Подробное ручное управление описано в руководстве по Codex CLI, автоматическое выполнение и триаж — в руководстве по Autopilot, а информация о сбоях — в руководстве по syzbot.

Ссылки

[1] Protect AI, «vulnhuntr», репозиторий GitHub. https://github.com/protectai/vulnhuntr

[2] Google, «syzkaller and syzbot», репозиторий GitHub. https://github.com/google/syzkaller

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

Лицензия

Лицензировано по Apache License 2.0.