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

RFC PATCH In review SJ Park 2 participants 3 messages Jun 28

Subsystems (3)

Stable branch Memory management DAMON

lore

Share & tools

lore

SJ Park

author maintainer

2026-06-28 16:55 UTC #0 lore raw

RFC PATCH 1/1 mm/damon/core: validate ranges in damon_set_regions()

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 <[email protected]> # 5.16.x

Signed-off-by SJ Park <[email protected]>

---
Changes from RFC v1.1
- RFC v1.1: https://lore.kernel.org/[email protected]
- Use ALIGN() for end address.
Changes from RFC v1
- RFC v1: https://lore.kernel.org/[email protected]
- 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(+)

mm/damon/core.c +6 -0

index d99f7a297fdde..949d5309d54d3 100644
@@ -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

Signature · 1 line

2.47.3

[email protected]

AI review

2026-06-28 17:09 UTC #1 lore raw

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

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

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.

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

Quoted 13 lines

mm/damon/core.c +6 -0

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

Signature · 1 line

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

SJ Park

author maintainer

2026-06-28 17:45 UTC #2 lore raw

Quoted 36 lines · On Sun, 28 Jun 2026 17:09:21 +0000 [email protected] 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 <[email protected]>
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.
mm/damon/core.c int damon_set_regions(struct damon_target *t, struct damon_addr_range *ranges, · line 365
Quoted 12 lines
mm/damon/core.c +5 -0
@@ -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.

Quoted 6 lines

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

[...]