CVE-2025-37858: 64-битное поле не исправляет узкий сдвиг

Где возникла ошибка вычисления

CVE-2025-37858 относится к расчёту размера группы размещения в dbExtendFS(), в файле fs/jfs/jfs_dmap.c. Использовалось выражение 1 << l2agsize. Объявление команды Linux CVE описывает сдвиги более чем на 31 бит в 32-битных системах, которые приводят к неопределённому поведению и некорректному размеру группы.

Важная деталь скрывается в самом выражении. Целочисленная константа 1 не становится 64-битным операндом только потому, что результат затем сохраняется в широком поле. Сначала выполняется сдвиг, потом присваивание. Проверка лишь типа поля пропускает операцию, которая формирует значение.

Расширение операнда до сдвига

Исправление приводит левый операнд к s64 до выполнения сдвига. Операция получает нужную разрядность, соответствующую полю размера группы. Ниже показано изменение выражения, описанное в публичном объявлении.

Приведение уже вычисленного результата происходит слишком поздно. Эта разница важна и для умножения, и для расчёта размера выделяемой памяти. Более широкий промежуточный тип тоже требует подходящей проверки диапазона: расширение само по себе не делает любой ввод безопасным.

- bmp->db_agsize = 1 << l2agsize;
+ bmp->db_agsize = (s64)1 << l2agsize;

Проверка промежуточных значений

Для каждого расчёта размера определите фактические типы операндов, знаковость и допустимый диапазон входных данных. Проверьте выражение до присваивания, включая преобразования и явные приведения типов. Рассмотрите поддерживаемые 32-битные и 64-битные конфигурации, если они меняют типы или поведение сборки.

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

Почему это важно и вне файловой системы

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

Такой подход полезен для нативного ПО, работающего с длинами, смещениями, буферами и недоверенными метаданными файлов. Целевой аудит безопасности кода проверяет вычисление вместе с операциями памяти или хранения, которыми оно управляет. Для установленного пакета Linux статус исправления определяйте по актуальной записи CVE и рекомендациям поставщика.