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

[SJ Park <sj@kernel.org>]

On Wed, 01 Jul 2026 16:22:20 +0000 sashiko-bot@kernel.org wrote:

> 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?

My previous reply [1] should be applied here.

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


Thanks,
SJ

[...]