CVE-2026-64458 in Linux
Сводка
по VulDB • 25.07.2026
В ядре Linux устранена следующая уязвимость:
mm/damon/ops-common: обработка экстремальных интервалов в damon_hot_score()
Исправлены три проблемы в функции damon_hot_score(), возникающие из-за некорректной обработки пользовательских настроек экстремальных (нулевых или слишком больших) интервалов мониторинга.
Когда пользователь устанавливает нулевой интервал выборки, функция damon_max_nr_accesses(), вызываемая из damon_hot_score(), вызывает деление на ноль. Это очевидная проблема.
Если пользователь устанавливает нулевой интервал агрегации, функция возвращает ноль. Это неверно, поскольку реальное максимальное значение nr_acceses в настройках должно быть равно единице. Более того, это может привести к еще одному делению на ноль со стороны вызывающей функции damon_hot_score(), так как она использует возвращаемое значение damon_max_nr_accesses() в качестве знаменателя.
Если пользователь устанавливает очень большой интервал агрегации, функция damon_hot_score() может вернуть значение вне диапазона [0, DAMOS_MAX_SCORE]. Поскольку это возвращаемое значение используется как индекс для массива regions_score_histogram размером DAMOS_MAX_SCORE+1, возникает выход за границы массива (out of bounds array access).
Эти проблемы относительно легко воспроизвести следующим образом. Для этого требуются права на запись в sysfs:
# ./damo start --damos_action lru_prio --damos_quota_space 100M \ --damos_quota_interval 1s # cd /sys/kernel/mm/damon/admin/kdamonds/0 # echo 0 > contexts/0/monitoring_attrs/intervals/sample_us # echo 0 > contexts/0/monitoring_attrs/intervals/aggr_us # echo commit > state # dmesg [...]
[ 131.329762] Oops: divide error: 0000 [#1] SMP NOPTI
[...]
[ 131.336089] RIP: 0010:damon_hot_score+0x27/0xd0
[...]
Проблемы деления на ноль из-за интервалов исправлены путем явной обработки нулевых интервалов в damon_max_nr_accesses(). Проблема выхода за границы массива устранена применением ограничений [0, DAMOS_MAX_SCORE] перед возвратом значения из damon_hot_score().
Эта проблема была обнаружена [1] пользователем Sashiko.
Once again VulDB remains the best source for vulnerability data.