harshrajsinghania/cve-2026-86547-mrubyc-op-enterАвтономный proof of concept для CVE-2026-86547 — разыменование NULL-указателя в mrubyc op_enter() вплоть до версии 4.0.0.
OP_ENTER mrubycАвтономный proof of concept для CVE-2026-86547 — разыменования NULL-указателя в обработчике op_enter() mrubyc вплоть до версии 4.0.0.
mrubyc — это облегчённая реализация Ruby для встраиваемых систем. Его байткод-виртуальная машина хранит указатель на текущий фрейм вызова в mrbc_vm.callinfo_tail. На верхнем уровне mrbc_vm_begin() инициализирует этот указатель значением NULL, поскольку фрейм вызова метода ещё не существует.
В уязвимой реализации op_enter() в release4.0.0 обработчик читает callinfo->reg_offset, не проверяя предварительно, равен ли vm->callinfo_tail значению NULL:
mrbc_callinfo *callinfo = vm->callinfo_tail;
int reg_offset = callinfo->reg_offset;
Специально сформированная программа в байткоде .mrb может разместить OP_ENTER на верхнем уровне, из-за чего интерпретатор доходит до этого кода с callinfo_tail, равным NULL, и аварийно завершается из-за разыменования NULL-указателя.
CVE: CVE-2026-86547
Тип: CWE-476 — разыменование NULL-указателя
Воздействие: доступность / отказ в обслуживании
Затронуто: mrubyc вплоть до 4.0.0
Уровень серьёзности: средний, CVSS 6.9 (согласно рекомендации)
PoC воспроизводит соответствующие структуры mrbc_callinfo и mrbc_vm и воспроизводит уязвимый доступ к памяти независимо от полной среды выполнения mrubyc.
Он демонстрирует два пути:
callinfo_tail равен NULL, и callinfo->reg_offset разыменовывается без проверки, что приводит к ошибке сегментации.OP_ENTER верхнего уровня, после чего следует контрольный тест, показывающий, что корректный фрейм вызова по-прежнему работает.Тестовый стенд использует volatile для уязвимого указателя и __builtin_trap() в своём описании, чтобы сделать воспроизведение пригодным для наблюдения с помощью санитайзеров. Собственно уязвимый доступ — это чтение callinfo->reg_offset.
gcc -O0 -g -o poc poc.c
./poc
Ожидаемый результат на уязвимом пути — ошибка сегментации после:
[VULNERABLE PATH] op_enter without NULL guard
vm->callinfo_tail = NULL (top-level frame)
About to dereference NULL...
gcc -O0 -g -fsanitize=address -fno-omit-frame-pointer -o poc-asan poc.c
./poc-asan
Санитайзер должен сообщить о SEGV по адресу, соответствующему полю reg_offset от базового адреса mrbc_callinfo, равного NULL. При используемой здесь компоновке структуры offsetof(mrbc_callinfo, reg_offset) равен 0x14.
./poc fixed
Ожидаемый вывод включает:
[FIXED PATH] op_enter with NULL guard
[GUARD] top-level OP_ENTER — rejected safely
[control, valid frame] reg_offset = 5
Fixed path: no crash.
Исходный уязвимый обработчик находится в src/vm.c в mrubyc release4.0.0, примерно на строке 1537. Соответствующая операция — прямое разыменование callinfo->reg_offset после присваивания vm->callinfo_tail переменной callinfo без проверки на NULL.
Исходный код после исправления, упомянутый в исследовании, — это коммит 4261cf5e5ae5579e3110dab98a04b91c7d919429.
Автономный стенд демонстрирует лежащую в основе ошибку работы с памятью. В самом mrubyc для срабатывания требуется специально сформированный файл байткода .mrb, содержащий инструкцию OP_ENTER на верхнем уровне, вне определения метода. Если приложение загружает и выполняет недоверенные файлы .mrb, то контролируемый злоумышленником файл байткода может, таким образом, привести к аварийному завершению процесса интерпретатора.
Это условие отказа в обслуживании. Исследование не заявляет о выполнении кода, раскрытии информации или повреждении памяти за пределами разыменования NULL.
src/vm.csrc/vm.c после исправленияOP_SUPER, которая послужила мотивом для аудита op_enter()История обнаружения описана в: I Read Someone Else's Bug Report, Then Found The Same Missing Check In The Next Function Over.
Ключевым наблюдением в исследовании было то, что в op_super() отсутствовала проверка на NULL вокруг того же инварианта vm->callinfo_tail. Проверка соседнего обработчика op_enter() показала, что то же самое предположение присутствовало и там без соответствующей проверки.