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

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 val=
idation.
- [Medium] The validation check unconditionally rejects valid monitoring ra=
nges 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 o=
verlapping monitoring regions from valid, non-overlapping user inputs.
--

--- Patch [1]: [PATCH 6.12.y] mm/damon/core: validate ranges in damon_set_r=
egions() ---
commit b519271ef73c8bbed5092bcf809ea6bc504693b6
Author: SJ Park <[email protected]>
Date:   Thu Jul 30 00:56:39 2026 +0000

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

Link: https://lore.kernel.org/[email protected]

> 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;
> =20
> +	for (i =3D 0; i < nr_ranges; i++) {
> +		if (ALIGN_DOWN(ranges[i].start, DAMON_MIN_REGION) >=3D
> +				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 =3D 4097,=20
end =3D 4097) via sysfs, ALIGN_DOWN evaluates to 4096 and ALIGN evaluates to
8192. The condition 4096 >=3D 8192 evaluates to false, which completely=20
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) >=3D 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 =3D 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.,=20
start =3D 0, end =3D 4097 and start =3D 4098, end =3D 8192), ALIGN_DOWN and=
 ALIGN=20
expand these to [0, 8192] and [4096, 8192], which overlap.

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

--=20
Sashiko AI review =C2=B7 https://sashiko.dev/#/patchset/20260730005639.1088=
[email protected]?part=3D1