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

[RFC PATCH v1.1] 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
- 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..df0cc699494fe 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_DOWN(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: 7c001190b88a32f80c93a6ac302af59a9756309c
-- 
2.47.3

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

[sashiko-bot]

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

New issues:
- [Critical] The new validation logic incorrectly uses `ALIGN_DOWN` for the region's end address, falsely rejecting valid sub-block monitoring regions and breaking the user API.
- [High] Integer overflow in `ALIGN()` bypasses the newly added validation check, failing to prevent the creation of zero-length regions.

Pre-existing issues:
- [High] sysfs interface allows `addr_unit` to be set such that `min_region_sz` is not a power of two, breaking alignment macros and corrupting boundaries.
--

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

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

DAMON core logic assumes zero length regions don't exist, but API callers allow
empty monitoring target regions. This patch adds validation in
damon_set_regions() to ensure start is strictly less than end after alignment.

> diff --git a/mm/damon/core.c b/mm/damon/core.c
> index 7e4b9affc5b06..cbdf29d119c93 100644
> --- 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_DOWN(ranges[i].end, min_region_sz))

[Severity: Critical]
Does this ALIGN_DOWN() on the end address incorrectly reject valid regions?

If a user configures a target region with start and end within the same
alignment boundary (for example, start=4096 and end=8191 with a
min_region_sz=4096), the check evaluates to 4096 >= 4096 and returns
-EINVAL. The previous behavior successfully expanded this to [4096, 8192)
using ALIGN(end). This seems to reject previously valid inputs.

[Severity: High]
Can an integer overflow here bypass the new validation check?

If a user specifies a region with an end address near ULONG_MAX,
ALIGN_DOWN(ULONG_MAX, min_region_sz) will evaluate to a large positive
value, which passes the start >= end check.

However, the region creation logic later uses ALIGN() on the end address:

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

ALIGN(ULONG_MAX, min_region_sz) overflows to 0, which means damon_new_region()
is still called with an end address of 0, bypassing this validation and
creating the exact zero-length region this patch intends to stop.

[Severity: High]
This is a pre-existing issue, but can min_region_sz be a non-power-of-two,
corrupting boundaries when passed to ALIGN_DOWN here?

The ALIGN and ALIGN_DOWN macros rely on bitwise masking, which requires
the alignment value to be a power of two.

Looking at how min_region_sz is calculated in damon_sysfs_apply_inputs():

mm/damon/sysfs.c:damon_sysfs_apply_inputs() {
    ...
		ctx->min_region_sz = max(
				DAMON_MIN_REGION_SZ / sys_ctx->addr_unit, 1);
    ...
}

If a user writes a value like 3 to addr_unit via sysfs, min_region_sz
becomes 1365 (4096 / 3). When 1365 is passed to ALIGN_DOWN here, the
macro produces garbage addresses.

> +			return -EINVAL;
> +	}
> +
>  	/* Remove regions which are not in the new ranges */
>  	damon_for_each_region_safe(r, next, t) {

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

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

[SJ Park]

On Sun, 28 Jun 2026 01:06:30 +0000 sashiko-bot@kernel.org wrote:

> Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
> 
> New issues:
> - [Critical] The new validation logic incorrectly uses `ALIGN_DOWN` for the region's end address, falsely rejecting valid sub-block monitoring regions and breaking the user API.
> - [High] Integer overflow in `ALIGN()` bypasses the newly added validation check, failing to prevent the creation of zero-length regions.
> 
> Pre-existing issues:
> - [High] sysfs interface allows `addr_unit` to be set such that `min_region_sz` is not a power of two, breaking alignment macros and corrupting boundaries.
> --
> 
> commit a7d14189013c68fcb3a5a9644321f7f319e6fe5f
> Author: SJ Park <sj@kernel.org>
> 
> mm/damon/core: validate ranges in damon_set_regions()
> 
> DAMON core logic assumes zero length regions don't exist, but API callers allow
> empty monitoring target regions. This patch adds validation in
> damon_set_regions() to ensure start is strictly less than end after alignment.
> 
> > diff --git a/mm/damon/core.c b/mm/damon/core.c
> > index 7e4b9affc5b06..cbdf29d119c93 100644
> > --- 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_DOWN(ranges[i].end, min_region_sz))
> 
> [Severity: Critical]
> Does this ALIGN_DOWN() on the end address incorrectly reject valid regions?
> 
> If a user configures a target region with start and end within the same
> alignment boundary (for example, start=4096 and end=8191 with a
> min_region_sz=4096), the check evaluates to 4096 >= 4096 and returns
> -EINVAL. The previous behavior successfully expanded this to [4096, 8192)
> using ALIGN(end). This seems to reject previously valid inputs.

Correct.  I mistakenly used ALIGN_DOWN() instead of ALIGN() for the end
address.  I will fix this in the next revision.

> 
> [Severity: High]
> Can an integer overflow here bypass the new validation check?
> 
> If a user specifies a region with an end address near ULONG_MAX,
> ALIGN_DOWN(ULONG_MAX, min_region_sz) will evaluate to a large positive
> value, which passes the start >= end check.
> 
> However, the region creation logic later uses ALIGN() on the end address:
> 
> mm/damon/core.c:damon_set_regions() {
>     ...
> 		for (i = 0; i < nr_ranges; i++) {
> 			r = damon_new_region(
> 					ALIGN_DOWN(ranges[i].start,
> 						min_region_sz),
> 					ALIGN(ranges[i].end, min_region_sz));
>     ...
> }
> 
> ALIGN(ULONG_MAX, min_region_sz) overflows to 0, which means damon_new_region()
> is still called with an end address of 0, bypassing this validation and
> creating the exact zero-length region this patch intends to stop.

Use of ALIGN_DOWN() for the end address was a mistake.  I will use ALIGN() for
the end address in the next spin.

> 
> [Severity: High]
> This is a pre-existing issue, but can min_region_sz be a non-power-of-two,
> corrupting boundaries when passed to ALIGN_DOWN here?
> 
> The ALIGN and ALIGN_DOWN macros rely on bitwise masking, which requires
> the alignment value to be a power of two.
> 
> Looking at how min_region_sz is calculated in damon_sysfs_apply_inputs():
> 
> mm/damon/sysfs.c:damon_sysfs_apply_inputs() {
>     ...
> 		ctx->min_region_sz = max(
> 				DAMON_MIN_REGION_SZ / sys_ctx->addr_unit, 1);
>     ...
> }
> 
> If a user writes a value like 3 to addr_unit via sysfs, min_region_sz
> becomes 1365 (4096 / 3). When 1365 is passed to ALIGN_DOWN here, the
> macro produces garbage addresses.

Wrong.  We have the power of 2 check in damon_commit_ctx() and damon_start().
So this issue cannot happen.


Thanks,
SJ

[...]