В современном мире машинного обучения и искусственного интеллекта безопасность программных компонентов становится не менее важной, чем их функциональность. Недавнее открытие уязвимости переполнения кучи в токенизаторе Llama.cpp стало серьезным вызовом для сообщества разработчиков и исследователей безопасности. Данная проблема скрывалась под поверхностью более года, и лишь автономный исследовательский агент Pwno смог выявить её глубинные причины и продемонстрировать потенциальные последствия. В основе уязвимости лежит тонкий баг, связанный с переполнением целочисленного значения, который приводит к возможности выхода за пределы выделенной памяти и переписыванию соседних участков — классической ошибке безопасности, называемой heap overflow.
Уникальность открытия заключается в том, что уязвимость затрагивает токенизатор — ключевой компонент языковых моделей, отвечающий за преобразование входного текста в последовательности токенов, на которых строится само машинное обучение. Проблема проявляется в функции llama_vocab::tokenize, где осуществляется преобразование результата размера вектора токенов из беззнакового типа size_t в знаковый int32_t. Такая трансформация происходит в условии сравнения, которое при определённых крайних условиях приводит к переполнению знакового типа и, как следствие, некорректному поведению программы. При больших размерах результата cast приводит к отрицательному значению, из-за чего условие сравнения с n_tokens_max, обычно небольшой по размеру переменной, принципиально искажается. В результате на этапе копирования токенов в аллоцированный буфер происходит выход за выделенную память, что формально является heap overflow.
Данная ошибка является не просто уроком по осторожному обращению с типами данных в C++, но и важным предупреждением о том, как даже тонкие дизайнерские решения могут создавать серьёзные дыры безопасности. Любопытно, что в процессе обнаружения проблемы исследователи Pwno столкнулись с преградами при попытках создать доказательство концепции (Proof-of-Concept): стандартная библиотека C++ имеет внутренние механизмы защиты, не позволяющие создать std::vector с очень большим размером, что блокировало преднамеренное воспроизведение ошибки. Однако, обходной путь был найден благодаря особенностям внутренней архитектуры llama.cpp: при активации Jinja шаблонов для обработки диалогов исключалась часть кода, вызывающая ошибку размера буфера. Это позволило обойти ограничения системных аллокаторов и протестировать вызов токенизатора с необходимыми параметрами.
Помимо heap overflow, в ходе исследования был выявлен и побочный эффект — потенциальная уязвимость ReDoS (Regular Expression Denial of Service) из-за бесконечной рекурсии в обработке регулярных выражений в разделе unicode_regex_split, что само по себе является серьёзной проблемой, способной привести к переполнению стека и блокировке сервиса. Авторы доклада сумели не только вскрыть суть бага и продемонстрировать пути его обхода, но и предоставить полную обратную связь сообществу llama.cpp, что позволило разработчикам оперативно отреагировать и выпустить патчи исправления в течение 24 часов с момента раскрытия. Такой подход к безопасности заслуживает высокой оценки и демонстрирует зрелость и ответственность команды, поддерживающей столь важный инфраструктурный проект в области ИИ. Последствия обнаруженной уязвимости выходят за рамки учебного примера.
Переполнение кучи предоставляет потенциальным злоумышленникам множество векторов атаки: от нарушения целостности приложения и краха inferencing-сервера до полномасштабного удалённого исполнения кода. Именно риск получения удалённого контроля над вычислительной системой делает ошибки подобного рода особенно опасными для инфраструктур, предоставляющих сервисы машинного обучения в облаке или на корпоративных платформах. Ранее в других компонентах машинного обучения, таких как GGUF пиарсер, наблюдались похожие проблемы, но случай с токенизатором Llama.cpp стал первой подобной уязвимостью на этом уровне. Это подчеркивает, как сложно обеспечить безопасность всех слоев сложной системы, и как важно исследовать самые фундаментальные компоненты с точки зрения безопасности.
Появление автономных систем исследователей безопасности, таких как Pwno, становится все более актуальным в эпоху масштабного распространения ИИ. Способность подобного агентства не только обнаружить баг, но и провести комплексный анализ и взаимодействовать с разработчиками, ускоряя процесс выявления и устранения уязвимостей, демонстрирует будущее безопасной разработки. Помимо технических деталей, важным уроком из раскрытия CVE-2025-52566 является осознание тонкости взаимодействия разных библиотек и компонентов ПО — особенно в условиях интенсивного использования шаблонных движков (Jinja), регулярных выражений и продвинутого механизма токенизации. Применение «двухфазного» подхода к выделению памяти, широко распространённого в llama.cpp, оказалось уязвимым к переполнению из-за некорректной работы с типами данных, что подчеркивает, что даже распространённые паттерны могут скрывать риски.
Заметный прогресс вызвало также понимание специфики токенизации с разными режимами, такими как Byte-Pair Encoding и Unigram модели. Благодаря выбору архитектуры токенизатора можно было обойти побочные эффекты, такие как бесконечная рекурсия при разбиении текста на слова, что увеличивает гибкость и безопасность системы. Для разработчиков и пользователей индустрии машинного обучения открытие CVE-2025-52566 — это сигнал о необходимости проведения регулярного аудита безопасности ключевых компонентов, даже тех, которые воспринимаются как зрелые и стабильные. Важно помнить, что вычислительные риски могут крыться в самых фундаментальных слоях стека ПО и что их своевременное выявление требует как человеческого участия, так и внедрения современных инструментов автоматизации. В заключение, данное исследование не только расширило границы знаний о мельчайших нюансах внутренней работы llama.
cpp, но и послужило отличным примером экологичного и ответственного взаимодействия между исследовательским сообществом и разработчиками. Благодаря быстро проведённому исправлению будет укреплена безопасность не только llama.cpp, но и многих проектов, зависящих от него, а тонкое понимание причини уязвимостей повысит общую устойчивость экосистемы машинного обучения на годы вперёд.
