В ядре Linux устранена следующая уязвимость:
mm/damon/ops-common: обработка крайних интервалов в damon_hot_score(). Исправлены три проблемы в damon_hot_score(), возникающие из-за неправильной обработки
крайние (нулевые или слишком высокие) интервалы мониторинга, устанавливаемые пользователем. Когда пользователь устанавливает нулевой интервал выборки, damon_max_nr_accesses(), который
вызывается из damon_hot_score(), вызывает деление на ноль.
Излишне скажем, это проблема. Когда пользователь устанавливает нулевой интервал агрегации, функция возвращает ноль. Это неправильно, так как реальное максимальное число доступов в настройке должно будь одним.
Хуже того, это может вызвать еще одно деление на ноль от вызывающей стороны:
damon_hot_score(), поскольку он использует возвращаемое значение damon_max_nr_accesses() в качестве
знаменатель. Когда пользователь устанавливает очень высокий интервал агрегирования, damon_hot_score()
может вернуть значение из диапазона [0, DAMOS_MAX_SCORE]. С момента возвращения
значение используется в качестве индекса массива Region_score_histogram, который
DAMOS_MAX_SCORE+1, это приводит к выходу за пределы массива.
Проблемы можно относительно легко воспроизвести, как показано ниже. sysfs
однако требуется разрешение на запись.
# ./damo start --damos_action lru_prio --damos_quota_space 100M \
--damos_quota_interval 1 с
# 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
# эхо-фиксация > состояние
# dmesg
[...]
[ 131.329762] К сожалению: ошибка деления: 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] Сашико.
Показать оригинальное описание (EN)
In the Linux kernel, the following vulnerability has been resolved: mm/damon/ops-common: handle extreme intervals in damon_hot_score() Fix three issues in damon_hot_score() that comes from wrong handling of extreme (zero or too high) monitoring intervals user setup. When the user sets sampling interval zero, damon_max_nr_accesses(), which is called from damon_hot_score(), causes a divide-by-zero. Needless to say, it is a problem. When the user sets the aggregation interval zero, the function returns zero. It is wrong, since the real maximum nr_acceses in the setup should be one. Worse yet, it can cause another divide-by-zero from its caller, damon_hot_score(), since it uses damon_max_nr_accesses() return value as a denominator. When the user sets the aggregation interval very high, damon_hot_score() could return a value out of [0, DAMOS_MAX_SCORE] range. Since the return value is used as an index to the regions_score_histogram array, which is DAMOS_MAX_SCORE+1 size, it causes out of bounds array access. The issues can be relatively easily reproduced like below. The sysfs write permission is required, though. # ./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 [...] Fix the divide-by-zero intervals problems by explicitly handling the zero intervals in damon_max_nr_accesses(). Fix the out-of-bound array access by applying [0, DAMOS_MAX_SCORE] bounds before returning from damon_hot_score(). The issue was discovered [1] by Sashiko.