About vulnerability

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.

Live-patch status from KernelCare for each operating system.