[PATCH v2] mm/damon/ops-common: handle extreme intervals in damon_hot_score()

[PATCH v2] mm/damon/ops-common: handle extreme intervals in damon_hot_score()

[SeongJae Park]

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.

[1] https://lore.kernel.org/20260619202459.145010-1-sj@kernel.org

Fixes: 198f0f4c58b9 ("mm/damon/vaddr,paddr: support pageout prioritization")
Cc: <stable@vger.kernel.org> # 5.16.x
Signed-off-by: SeongJae Park <sj@kernel.org>
---
Changes from RFC v1.3
- RFC v1.3: https://lore.kernel.org/20260623011652.1354-1-sj@kernel.org
- Drop RFC again.
Changes from RFC v1.2
- RFC v1.2: https://lore.kernel.org/20260622141027.29145-1-sj@kernel.org
- Drop patch 2 and make patch 1 fixes all damon_hot_score() problems.
Changes from v1
- v1: https://lore.kernel.org/20260621154808.86431-1-sj@kernel.org
- Add out-of-bound array access bug fix as patch 2.
- Add the RFC tag again.
Changes from RFC v1.1
- RFC v1.1: https://lore.kernel.org/20260620171413.89555-1-sj@kernel.org
- Wordsmith commit message.
- Drop RFC tag.
Changes from RFC v1
- RFC v1: https://lore.kernel.org/20260619205144.150664-1-sj@kernel.org
- Handle zero aggr_interval case.

 include/linux/damon.h | 8 ++++++--
 mm/damon/ops-common.c | 1 +
 2 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/include/linux/damon.h b/include/linux/damon.h
index 6f7edb3590ef9..888570f55b416 100644
--- a/include/linux/damon.h
+++ b/include/linux/damon.h
@@ -1065,9 +1065,13 @@ static inline bool damon_target_has_pid(const struct damon_ctx *ctx)
 
 static inline unsigned int damon_max_nr_accesses(const struct damon_attrs *attrs)
 {
-	/* {aggr,sample}_interval are unsigned long, hence could overflow */
-	return min(attrs->aggr_interval / attrs->sample_interval,
+	unsigned long sample_interval;
+	unsigned long max_nr_accesses;
+
+	sample_interval = attrs->sample_interval ? : 1;
+	max_nr_accesses = min(attrs->aggr_interval / sample_interval,
 			(unsigned long)UINT_MAX);
+	return max_nr_accesses ? : 1;
 }
 
 
diff --git a/mm/damon/ops-common.c b/mm/damon/ops-common.c
index 5c93ef2bb8a97..d1842e2b00ef8 100644
--- a/mm/damon/ops-common.c
+++ b/mm/damon/ops-common.c
@@ -143,6 +143,7 @@ int damon_hot_score(struct damon_ctx *c, struct damon_region *r,
 	 * Transform it to fit in [0, DAMOS_MAX_SCORE]
 	 */
 	hotness = hotness * DAMOS_MAX_SCORE / DAMON_MAX_SUBSCORE;
+	hotness = max(min(hotness, DAMOS_MAX_SCORE), 0);
 
 	return hotness;
 }

base-commit: c12377ad97c98e0bee10870abf4ab1101a946b4c
-- 
2.47.3

Re: [PATCH v2] mm/damon/ops-common: handle extreme intervals in damon_hot_score()

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:

Pre-existing issues:
- [High] Multiplication in `freq_subscore` calculation overflows 32-bit `unsigned int` for extreme intervals, reversing region hotness prioritization.
- [High] User-supplied sysfs weights can overflow, resulting in a bypassed division and Signed Integer Overflow (UB).
--

commit 8323dd74c4905401bc8701431eb5fd1a6b12a452
Author: SeongJae Park <sj@kernel.org>

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.

Link: https://lore.kernel.org/20260619202459.145010-1-sj@kernel.org

> diff --git a/mm/damon/ops-common.c b/mm/damon/ops-common.c
> index 5c93ef2bb8a97..d1842e2b00ef8 100644
> --- a/mm/damon/ops-common.c
> +++ b/mm/damon/ops-common.c
> @@ -143,6 +143,7 @@ int damon_hot_score(struct damon_ctx *c, struct damon_region *r,

[Severity: High]
This isn't a bug introduced by this patch, but could the freq_subscore
calculation overflow earlier in this function?

If a user configures a normal sample_interval (e.g., 100us) but a long
aggr_interval (e.g., 2 hours), r->nr_accesses can legitimately reach
72,000,000.

mm/damon/ops-common.c:damon_hot_score() {
    ...
    freq_subscore = r->nr_accesses * DAMON_MAX_SUBSCORE /
                    damon_max_nr_accesses(&c->attrs);
    ...
}

The multiplication of r->nr_accesses * DAMON_MAX_SUBSCORE (100) evaluates
to 7,200,000,000, which wraps around modulo 2^32, causing extremely hot
memory regions to be incorrectly scored as completely cold.

[Severity: High]
This is also a pre-existing issue, but can user-supplied sysfs weights
overflow and bypass the averaging division before this transformation?

mm/damon/ops-common.c:damon_hot_score() {
    ...
    if (freq_weight + age_weight)
        hotness /= freq_weight + age_weight;
    ...
}

If a user supplies weights for weight_nr_accesses and weight_age whose
sum is exactly UINT_MAX + 1 (e.g., 4,000,000,000 and 294,967,296), the
unsigned addition overflows to 0.

This causes the branch to evaluate as false, bypassing the averaging
division. The unaveraged weighted sum then evaluates to a large positive
integer.

>  	 * Transform it to fit in [0, DAMOS_MAX_SCORE]
>  	 */
>  	hotness = hotness * DAMOS_MAX_SCORE / DAMON_MAX_SUBSCORE;

Multiplying it by DAMOS_MAX_SCORE (99) here then overflows the signed int
result, resulting in undefined behavior.

> +	hotness = max(min(hotness, DAMOS_MAX_SCORE), 0);
>  
>  	return hotness;
>  }

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260623135834.67189-1-sj@kernel.org?part=1

Re: [PATCH v2] mm/damon/ops-common: handle extreme intervals in damon_hot_score()

[SeongJae Park]

On Tue, 23 Jun 2026 14:15:26 +0000 sashiko-bot@kernel.org wrote:

> Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
> 
> Pre-existing issues:
> - [High] Multiplication in `freq_subscore` calculation overflows 32-bit `unsigned int` for extreme intervals, reversing region hotness prioritization.
> - [High] User-supplied sysfs weights can overflow, resulting in a bypassed division and Signed Integer Overflow (UB).

Sashiko acknowledges both are pre-existing issue, so no blocker for this patch.

Also, both issues happen only under extreme and never common user setups, and
causing only DAMON internal behavioral degradation.  No critical issues like
panic or memory corruption will happen.  These are known low priority issues,
not a blocker of this patch.


Thanks,
SJ

[...]