FAILED: patch "[PATCH] mm/damon/core: validate ranges in damon_set_regions()" failed to apply to 6.1-stable tree
Subsystems (3)
[email protected]
maintainerThe patch below does not apply to the 6.1-stable tree.
If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <[email protected]>.
To reproduce the conflict and resubmit, you may use the following commands:
git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-6.1.y
git checkout FETCH_HEAD
git cherry-pick -x 1292c0ecb1caefb8ca064a3639d5673991e8810c
# <resolve conflicts, build, test, etc.>
git commit -s
git send-email --to '<[email protected]>' --in-reply-to '2026072901-stapling-parkway-4887@gregkh' --subject-prefix 'PATCH 6.1.y' 'HEAD^..'
Possible dependencies:
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
From 1292c0ecb1caefb8ca064a3639d5673991e8810c Mon Sep 17 00:00:00 2001
From: SJ Park <[email protected]>
Date: Mon, 29 Jun 2026 20:52:19 -0700
Subject: [PATCH] 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.
mm/damon/core.c +6 -0
@@ -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++) {
SJ Park
maintainerPATCH 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.
--- mm/damon/core.c | 6 ++++++ 1 file changed, 6 insertions(+)
mm/damon/core.c +6 -0
@@ -212,6 +212,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 ; + } +/* Remove regions which are not in the new ranges */ damon_for_each_region_safe (r, next, t) {for (i =0 ; i < nr_ranges; i++) {
Signature · 1 line
2.47.3
[email protected]
AI reviewRe: [PATCH 6.1.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:
Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
New issues:
- [High] The validation check fails to consistently reject unaligned zero-length regions, allowing them to bypass validation and silently expand.
- [High] The ALIGN() macro overflows to 0 when evaluating regions near the end of the 32-bit address space, causing valid regions to be erroneously rejected.
Pre-existing issues:
- [High] Pre-existing leak of struct pid references if target addition or context setup fails during sysfs input application. --
--- Patch [1]: [PATCH 6.1.y] mm/damon/core: validate ranges in damon_set_regions() --- commit a1c890d67da57c98800fdd95b91daeac6ab475ab
Author: SJ Park <[email protected]>
mm/damon/core: validate ranges in damon_set_regions()
This commit adds a validation check in damon_set_regions() to ensure that the provided region ranges are valid. It aims to prevent empty or negative length regions from causing warnings and divide-by-zero errors in the core logic.
mm/damon/core.c int damon_set_regions(struct damon_target *t, struct damon_addr_range *ranges, · line 217
Quoted 11 lines
mm/damon/core.c +3
-0@@ -212,6 +212,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 ))
[Severity: High]
Does this logic successfully catch unaligned zero-length regions?
If a user configures a region with start and end both at an unaligned address like 4097, ALIGN_DOWN(4097) evaluates to 4096, and ALIGN(4097) evaluates to 8192. The check 4096 >= 8192 is false, which allows the invalid empty region to bypass validation and silently expand into a full page.
[Severity: High]
Will this ALIGN() check overflow on 32-bit systems when evaluating regions near the end of the address space?
If the end address of the physical memory resource is ULONG_MAX (0xFFFFFFFF), ALIGN(0xFFFFFFFF, 4096) overflows the 32-bit unsigned integer and evaluates to 0. This makes the check ALIGN_DOWN(start) >= 0 unconditionally true, which erroneously rejects valid memory regions and prevents DAMON initialization.
mm/damon/core.c int damon_set_regions(struct damon_target *t, struct damon_addr_range *ranges, · line 221
Quoted 4 lines
mm/damon/core.c +3
-0+return -EINVAL ; + } +/* Remove regions which are not in the new ranges */
[Severity: High]
This is a pre-existing issue, but does damon_destroy_ctx() leak struct pid references if context setup fails?
Looking at damon_sysfs_build_ctx() in mm/damon/sysfs.c:
err = damon_sysfs_apply_inputs(ctx, sys_ctx);
if (err) {
damon_destroy_ctx(ctx);
return ERR_PTR(err);
}If damon_sysfs_apply_inputs() successfully adds targets (incrementing struct pid refcounts) but a subsequent step fails, damon_destroy_ctx() is called.
Since vaddr ops do not define a .cleanup callback and the before_terminate callback is never executed, the damon_target structures are freed without calling put_pid(), permanently leaking the PID references.
Signature · 1 line
Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=1
SJ Park
maintainerRe: [PATCH 6.1.y] mm/damon/core: validate ranges in damon_set_regions()
Quoted 37 lines · On Thu, 30 Jul 2026 01:18:26 +0000 [email protected] wrote:
Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
New issues:
- [High] The validation check fails to consistently reject unaligned zero-length regions, allowing them to bypass validation and silently expand.
- [High] TheALIGN()macro overflows to 0 when evaluating regions near the end of the 32-bit address space, causing valid regions to be erroneously rejected.Pre-existing issues:
- [High] Pre-existing leak ofstruct pidreferences if target addition or context setup fails during sysfs input application. ----- Patch [1]: [PATCH 6.1.y]
mm/damon/core: validate ranges indamon_set_regions()--- commita1c890d67da57c98800fdd95b91daeac6ab475ab
Author: SJ Park <[email protected]>
mm/damon/core: validate ranges indamon_set_regions()This commit adds a validation check in
damon_set_regions()to ensure that the provided region ranges are valid. It aims to prevent empty or negative length regions from causing warnings and divide-by-zero errors in the core logic.mm/damon/core.c int damon_set_regions(struct damon_target *t, struct damon_addr_range *ranges, · line 217
Quoted 11 lines
mm/damon/core.c +3
-0@@ -212,6 +212,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 ))[Severity: High]
Does this logic successfully catch unaligned zero-length regions?
Quoted 4 lines
If a user configures a region with start and end both at an unaligned address like 4097,
ALIGN_DOWN(4097)evaluates to 4096, and ALIGN(4097) evaluates to 8192. The check 4096 >= 8192 is false, which allows the invalid empty region to bypass validation and silently expand into a full page.
No problem. It is an intended behavior.
Quoted 9 lines
[Severity: High]
Will thisALIGN()check overflow on 32-bit systems when evaluating regions near the end of the address space?If the end address of the physical memory resource is
ULONG_MAX(0xFFFFFFFF),ALIGN(0xFFFFFFFF, 4096)overflows the 32-bit unsigned integer and evaluates to 0. This makes the checkALIGN_DOWN(start)>= 0 unconditionally true, which erroneously rejects valid memory regions and prevents DAMON initialization.
For 32 bit systems having >4GiB memory, we provide addr_unit feature. The user could avoid the issue by using that. So no problem.
Quoted 18 lines
mm/damon/core.c int damon_set_regions(struct damon_target *t, struct damon_addr_range *ranges, · line 221
Quoted 5 lines
mm/damon/core.c +3
-0+return -EINVAL ; + } +/* Remove regions which are not in the new ranges */ [Severity: High]
This is a pre-existing issue, but doesdamon_destroy_ctx()leak struct pid references if context setup fails?Looking at
damon_sysfs_build_ctx()inmm/damon/sysfs.c:err = damon_sysfs_apply_inputs(ctx, sys_ctx); if (err) { damon_destroy_ctx(ctx); return ERR_PTR(err); }
Quoted 6 lines
If
damon_sysfs_apply_inputs()successfully adds targets (incrementing struct pid refcounts) but a subsequent step fails,damon_destroy_ctx()is called.Since vaddr ops do not define a .cleanup callback and the
before_terminatecallback is never executed, thedamon_targetstructures are freed without callingput_pid(), permanently leaking the PID references.
Good finding. Mainline tree avoided this issue by refactoring the code, with commits including 7114bc5e01cf ("mm/damon/core: add cleanup_target() ops callback"). Porting the all commits would be challenging. I will work on this with a dedicated fix.
Quoted 3 lines
Signature · 2 lines
-- Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=1
Thanks,
SJ
Re: [PATCH 6.1.y] mm/damon/core: validate ranges in damon_set_regions()
In reply to SJ ParkQuoted 2 lines · SJ Park
All DAMON API callers eventually use
damon_set_regions()to setup the regions. Add the validation logic in the function.
Queued for 6.1, thanks.
Signature · 2 lines
Thanks, Sasha