CVE-2026-64458

In the Linux kernel, the following vulnerability has been resolved:

mm/damon/ops-common: handle extreme intervals in damonhotscore()

Fix three issues in damonhotscore() that comes from wrong handling of extreme (zero or too high) monitoring intervals user setup.

When the user sets sampling interval zero, damonmaxnraccesses(), which is called from damonhot_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 nracceses in the setup should be one. Worse yet, it can cause another divide-by-zero from its caller, damonhotscore(), since it uses damonmaxnraccesses() return value as a denominator.

When the user sets the aggregation interval very high, damonhotscore() could return a value out of [0, DAMOSMAXSCORE] range. Since the return value is used as an index to the regionsscorehistogram array, which is DAMOSMAXSCORE+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 damonmaxnraccesses(). Fix the out-of-bound array access by applying [0, DAMOSMAXSCORE] bounds before returning from damonhot_score().

The issue was discovered [1] by Sashiko.