Re: [PATCH 6.12.y] mm/damon/core: validate ranges in damon_set_regions()

[sashiko-bot@kernel.org]

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

New issues:
- [High] The newly added validation check incorrectly uses alignment macros, allowing unaligned zero-length or inverted regions to silently bypass validation.
- [Medium] The validation check unconditionally rejects valid monitoring ranges ending near the top of the address space due to an integer overflow in the ALIGN macro.

Pre-existing issues:
- [High] Alignment rounding combined with a flawed iteration loop creates overlapping monitoring regions from valid, non-overlapping user inputs.
--

--- Patch [1]: [PATCH 6.12.y] mm/damon/core: validate ranges in damon_set_regions() ---
commit b519271ef73c8bbed5092bcf809ea6bc504693b6
Author: SJ Park <sj@kernel.org>
Date:   Thu Jul 30 00:56:39 2026 +0000

mm/damon/core: validate ranges in damon_set_regions()
    
This commit attempts to validate regions in damon_set_regions() to reject 
zero length monitoring target regions, which could previously trigger a 
divide-by-zero or WARN_ONCE.

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

> diff --git a/mm/damon/core.c b/mm/damon/core.c
> index 7911599c37f22..7217bb2ef51ec 100644
> --- a/mm/damon/core.c
> +++ b/mm/damon/core.c
> @@ -214,6 +214,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, DAMON_MIN_REGION) >=
> +				ALIGN(ranges[i].end, DAMON_MIN_REGION))
> +			return -EINVAL;
> +	}
> +

[Severity: High]
Does this validation logic allow unaligned zero-length or inverted regions
to bypass the check?

If a user configures an unaligned empty region (e.g., start = 4097, 
end = 4097) via sysfs, ALIGN_DOWN evaluates to 4096 and ALIGN evaluates to
8192. The condition 4096 >= 8192 evaluates to false, which completely 
bypasses the rejection of the invalid region.

[Severity: Medium]
Will this check unconditionally reject valid monitoring ranges ending near the
top of the address space?

If a caller specifies a monitoring region ending near ULONG_MAX, the
ALIGN(ranges[i].end, DAMON_MIN_REGION) operation could wrap around to 0.
This would cause the unsigned comparison ALIGN_DOWN(start) >= 0 to always
evaluate to true, resulting in a false positive -EINVAL rejection.

[Severity: High]
This is a pre-existing issue, but does alignment rounding combined with the
iteration loop create overlapping monitoring regions from valid,
non-overlapping user inputs?

mm/damon/core.c:damon_set_regions() {
    ...
    if (!first) {
        /* no region intersects with this range */
        newr = damon_new_region(
                ALIGN_DOWN(range->start,
                    DAMON_MIN_REGION),
                ALIGN(range->end, DAMON_MIN_REGION));
        if (!newr)
            return -ENOMEM;
        damon_insert_region(newr, damon_prev_region(r), r, t);
    } else {
    ...
}

If a user configures adjacent, non-overlapping unaligned ranges (e.g., 
start = 0, end = 4097 and start = 4098, end = 8192), ALIGN_DOWN and ALIGN 
expand these to [0, 8192] and [4096, 8192], which overlap.

Furthermore, because the loop cursor is not reset, intersection checks are 
skipped for subsequent ranges once the list end is reached. Could this cause 
these overlapping regions to be blindly inserted, potentially corrupting 
core data structures?

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