From: sashiko-bot@kernel.org
To: "SJ Park" <sj@kernel.org>
Cc: damon@lists.linux.dev
Subject: Re: [PATCH 6.1.y] mm/damon/core: validate ranges in damon_set_regions()
Date: Thu, 30 Jul 2026 01:18:26 +0000 [thread overview]
Message-ID: <20260730011827.71CE11F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260730010151.119009-1-sj@kernel.org>
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 <sj@kernel.org>
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.
Link: https://lore.kernel.org/20260630035221.146458-1-sj@kernel.org
> diff --git a/mm/damon/core.c b/mm/damon/core.c
> index 4b434ebd37c53..0a0bb033f28a4 100644
> --- a/mm/damon/core.c
> +++ b/mm/damon/core.c
> @@ -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.
> + 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.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260730010151.119009-1-sj@kernel.org?part=1
next prev parent reply other threads:[~2026-07-30 1:18 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <2026072901-stapling-parkway-4887@gregkh>
2026-07-30 1:01 ` [PATCH 6.1.y] mm/damon/core: validate ranges in damon_set_regions() SJ Park
2026-07-30 1:18 ` sashiko-bot [this message]
2026-07-30 4:07 ` SJ Park
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260730011827.71CE11F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=damon@lists.linux.dev \
--cc=sashiko-reviews@lists.linux.dev \
--cc=sj@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.