Re: [RFC PATCH 7/8] mm/damon/core: remove start, end check in damon_set_region_system_rams()

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Removal of bounds validation permits inverted regions (start > end), leading to a massive integer underflow and guaranteed OOM kernel panic.
--

commit 03335779d391504c4265be49dedb155969cf1a7d
Author: SJ Park <sj@kernel.org>

mm/damon/core: remove start, end check in damon_set_region_system_rams()

This commit removes the explicit start > end validation in
damon_set_region_system_rams_default(), stating that damon_set_regions()
already performs a complete check.

> diff --git a/mm/damon/core.c b/mm/damon/core.c
> index ace202f47dd7c..f491a76c98bfc 100644
> --- a/mm/damon/core.c
> +++ b/mm/damon/core.c
> @@ -3794,9 +3794,6 @@ int damon_set_region_system_rams_default(struct damon_target *t,
>  {
>  	struct damon_addr_range addr_range;
>  
> -	if (*start > *end)
> -		return -EINVAL;
> -
[Severity: High]
The commit message states that the complete check is done inside
damon_set_regions(), but does damon_set_regions() actually validate that
start is less than or equal to end?

Looking at damon_set_regions(), it appears to blindly create the region
with underflowed sizes if start > end:

mm/damon/core.c:damon_set_regions() {
        ...
        r = damon_new_region(
                ALIGN_DOWN(ranges[i].start, min_region_sz),
                ALIGN(ranges[i].end, min_region_sz));
        ...
}

If an inverted region (e.g., [4096, 0)) is passed in, could this lead to a
massive integer underflow? The size of the region would underflow to roughly
ULONG_MAX.

Later in damon_apply_min_nr_regions(), this underflow seems to translate
into an effectively infinite loop:

mm/damon/core.c:damon_apply_min_nr_regions() {
        ...
        while (damon_sz_region(r) > max_region_sz) {
                damon_split_region_at(t, r, max_region_sz);
                r = damon_next_region(r);
        }
        ...
}

Could this loop exhaust system memory by attempting to allocate quadrillions
of regions and cause an OOM kernel panic?

>  	if (!*start && !*end &&
>  		!damon_find_system_rams_range(start, end, addr_unit))
>  		return -EINVAL;

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