[RFC PATCH v1.2] mm/damon/core: validate ranges in damon_set_regions()

[RFC PATCH v1.2] mm/damon/core: validate ranges in damon_set_regions()

[SJ Park]

DAMON core logic assumes zero length regions don't exist.  However, a
few DAMON API callers including DAMON_SYSFS, DAMON_RECLAIM and
DAMON_LRU_SORT allow users to set empty monitoring target regions.  This
could result in WARN_ONCE() on CONFIG_DAMON_DEBUG_SANITY enabled kernel,
and divide-by-zero from damon_merge_two_regions().

For example, the WANR_ONCE() can be triggered like below.

    # grep DAMON_DEBUG_SANITY /boot/config-$(uname -r)
    # CONFIG_DAMON_DEBUG_SANITY=y
    # damo start
    # cd /sys/kernel/mm/damon/admin/kdamonds/0
    # echo 0 > contexts/0/targets/0/regions/0/start
    # echo 0 > contexts/0/targets/0/regions/0/end
    # echo commit > state
    # dmesg
    [....]
    [   73.705780] ------------[ cut here ]------------
    [   73.707552] start 0 >= end 0
    [   73.708452] WARNING: mm/damon/core.c:359 at damon_new_region+0x6e/0x80, CPU#1: kdamond.0/758
    [...]

All DAMON API callers eventually use damon_set_regions() to setup the
regions.  Add the validation logic in the function.

Fixes: 43b0536cb471 ("mm/damon: introduce DAMON-based Reclamation (DAMON_RECLAIM)")
Cc: <stable@vger.kernel.org> # 5.16.x
Signed-off-by: SJ Park <sj@kernel.org>
---
Changes from RFC v1.1
- RFC v1.1: https://lore.kernel.org/20260628005723.28549-1-sj@kernel.org
- Use ALIGN() for end address.
Changes from RFC v1
- RFC v1: https://lore.kernel.org/20260627170057.1867-1-sj@kernel.org
- Fixup the commit message for how the fix is made.
- Do the validation with min_region_sz-aligned addresses.

FYI, this fix cannot be applied as is to the commit that introduced this
class of bugs, because damon_set_regions() was introduced after the bug.
I considered making three fixes for each caller to make the backporting
on the old kernels easy.  However, the first LTS kernel having the bug
is 6.1.y, which has damon_set_regions() and all the callers are using
it.  So porting this to necessary stable kernels should be easy enough.

 mm/damon/core.c | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/mm/damon/core.c b/mm/damon/core.c
index d99f7a297fdde..949d5309d54d3 100644
--- a/mm/damon/core.c
+++ b/mm/damon/core.c
@@ -356,6 +356,12 @@ int damon_set_regions(struct damon_target *t, struct damon_addr_range *ranges,
 	unsigned int i;
 	int err;
 
+	for (i = 0; i < nr_ranges; i++) {
+		if (ALIGN_DOWN(ranges[i].start, min_region_sz) >=
+				ALIGN(ranges[i].end, min_region_sz))
+			return -EINVAL;
+	}
+
 	/* Remove regions which are not in the new ranges */
 	damon_for_each_region_safe(r, next, t) {
 		for (i = 0; i < nr_ranges; i++) {

base-commit: a5e5bb743e4c174689e5d57b25fa8c78c49546e8
-- 
2.47.3

Re: [RFC PATCH v1.2] mm/damon/core: validate ranges in damon_set_regions()

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] Flawed Validation Logic for Empty and Inverted Regions
--

commit 663c371bd35c3a6e3044a1a0a7c4a31852e3924f
Author: SJ Park <sj@kernel.org>

mm/damon/core: validate ranges in damon_set_regions()

This commit adds validation logic to damon_set_regions() to ensure that 
empty monitoring target regions are rejected. This prevents division-by-zero 
errors and sanity check warnings within the DAMON core logic.

> diff --git a/mm/damon/core.c b/mm/damon/core.c
> --- a/mm/damon/core.c
> +++ b/mm/damon/core.c
> @@ -358,6 +358,12 @@ int damon_set_regions(struct damon_target *t, struct damon_addr_range *ranges,
>  	unsigned int i;
>  	int err;
>  
> +	for (i = 0; i < nr_ranges; i++) {
> +		if (ALIGN_DOWN(ranges[i].start, min_region_sz) >=
> +				ALIGN(ranges[i].end, min_region_sz))
> +			return -EINVAL;
> +	}
> +

[Severity: Medium]
Does this validation logic correctly reject unaligned empty or inverted
ranges?

It looks like the alignment macros are applied before evaluating the bounds.
If a caller provides an unaligned empty range like [4097, 4097], ALIGN_DOWN 
makes the start 4096, and ALIGN makes the end 8192. This evaluates to 
4096 >= 8192, which is false, allowing the empty range to bypass the check 
and silently expand into a valid monitoring region.

Conversely, a page-aligned empty range like [4096, 4096] evaluates as 
4096 >= 4096 and is correctly rejected. Similarly, an inverted range like 
[4000, 3000] would align to [0, 4096) and be accepted.

Should the raw input bounds (ranges[i].start >= ranges[i].end) be validated
prior to applying the alignment macros?

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

Re: [RFC PATCH v1.2] mm/damon/core: validate ranges in damon_set_regions()

[SJ Park]

On Sun, 28 Jun 2026 17:09:21 +0000 sashiko-bot@kernel.org wrote:

> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> - [Medium] Flawed Validation Logic for Empty and Inverted Regions
> --
> 
> commit 663c371bd35c3a6e3044a1a0a7c4a31852e3924f
> Author: SJ Park <sj@kernel.org>
> 
> mm/damon/core: validate ranges in damon_set_regions()
> 
> This commit adds validation logic to damon_set_regions() to ensure that 
> empty monitoring target regions are rejected. This prevents division-by-zero 
> errors and sanity check warnings within the DAMON core logic.
> 
> > diff --git a/mm/damon/core.c b/mm/damon/core.c
> > --- a/mm/damon/core.c
> > +++ b/mm/damon/core.c
> > @@ -358,6 +358,12 @@ int damon_set_regions(struct damon_target *t, struct damon_addr_range *ranges,
> >  	unsigned int i;
> >  	int err;
> >  
> > +	for (i = 0; i < nr_ranges; i++) {
> > +		if (ALIGN_DOWN(ranges[i].start, min_region_sz) >> +				ALIGN(ranges[i].end, min_region_sz))
> > +			return -EINVAL;
> > +	}
> > +
> 
> [Severity: Medium]
> Does this validation logic correctly reject unaligned empty or inverted
> ranges?
> 
> It looks like the alignment macros are applied before evaluating the bounds.
> If a caller provides an unaligned empty range like [4097, 4097], ALIGN_DOWN 
> makes the start 4096, and ALIGN makes the end 8192. This evaluates to 
> 4096 >= 8192, which is false, allowing the empty range to bypass the check 
> and silently expand into a valid monitoring region.
> 
> Conversely, a page-aligned empty range like [4096, 4096] evaluates as 
> 4096 >= 4096 and is correctly rejected. Similarly, an inverted range like 
> [4000, 3000] would align to [0, 4096) and be accepted.
> 
> Should the raw input bounds (ranges[i].start >= ranges[i].end) be validated
> prior to applying the alignment macros?

Sashiko's behavior expectation is correct.  And that could be not really good
user experience.  But I think that's what we could improve in future unless it
introduces too much complexity, rather than somewhat need to be implemented
right now blocking this fix.

So, no blocker.  I will consider improving the user experience as a future
work.


Thanks,
SJ

[...]