FAILED: patch "[PATCH] mm/damon/core: validate ranges in damon_set_regions()" failed to apply to 6.12-stable tree

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 <[email protected]>
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/[email protected] open here

Quoted 5 lines

mm/damon/core.c +0 -0

index 7911599c37f22..7217bb2ef51ec 100644

mm/damon/core.c int damon_set_regions(struct damon_target *t, struct damon_addr_range *ranges, · line 222

Quoted 9 lines

mm/damon/core.c +6 -0

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

Signature · 2 lines

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=1