From: SJ Park <sj@kernel.org>
To: sashiko-bot@kernel.org
Cc: SJ Park <sj@kernel.org>, damon@lists.linux.dev
Subject: Re: [RFC PATCH 5/8] mm/damon/sysfs-schemes: drop centralized filter range arg validations
Date: Sat, 12 Sep 2026 12:43:17 -0700 [thread overview]
Message-ID: <20260912194318.139608-1-sj@kernel.org> (raw)
In-Reply-To: <20260912193003.54B061F000FF@smtp.kernel.org>
On Sat, 12 Sep 2026 19:30:02 +0000 sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> - [High] Removing the filter range argument validation in `damon_sysfs_add_scheme_filters()` relies on the core layer to perform this validation. However, the core layer's commit functions (`damos_commit_core_filters()` and `damos_commit_ops_filters()`) silently ignore the return value of `damos_commit_filter_arg()` when adding new filters. When an invalid range is provided via sysfs, `damos_commit_filter_arg()` returns `-EINVAL` and aborts before copying the arguments. Because `damos_new_filter()` uses `kmalloc_obj()` (which does not zero memory), the new filter's union arguments (e.g., `addr_range`) are left completely uninitialized. The filter is then added to the active DAMON context, resulting in the scheme acting on an unpredictable memory range derived from uninitialized heap garbage.
> --
>
> commit a45f05608fa3c7f9050ea4eac0fd8f19b22ee509
> Author: SJ Park <sj@kernel.org>
>
> mm/damon/sysfs-schemes: drop centralized filter range arg validations
>
> This patch drops the centralized filter range argument validations in the
> DAMON sysfs interface, relying on the core layer to perform this validation.
>
> > diff --git a/mm/damon/sysfs-schemes.c b/mm/damon/sysfs-schemes.c
> > index 8c8ab82c8facc..a4ec5d54cfbd1 100644
> > --- a/mm/damon/sysfs-schemes.c
> > +++ b/mm/damon/sysfs-schemes.c
>
> [ ... ]
>
> > @@ -2832,27 +2832,14 @@ static int damon_sysfs_add_scheme_filters(struct damos *scheme,
> > }
> > } else if (filter->type == DAMOS_FILTER_TYPE_ADDR) {
> > filter->addr_range = sysfs_filter->addr_range;
> > - if (filter->addr_range.end <
> > - filter->addr_range.start) {
> > - damos_destroy_filter(filter);
> > - return -EINVAL;
> > - }
> > } else if (filter->type == DAMOS_FILTER_TYPE_TARGET) {
> > filter->target_idx = sysfs_filter->target_idx;
> > } else if (filter->type == DAMOS_FILTER_TYPE_HUGEPAGE_SIZE) {
> > filter->sz_range.min = sysfs_filter->range_min;
> > filter->sz_range.max = sysfs_filter->range_max;
> > - if (filter->range_min > filter->range_max) {
> > - damos_destroy_filter(filter);
> > - return -EINVAL;
> > - }
>
> [Severity: High]
> Does removing this validation allow invalid ranges to bypass sysfs and reach
> the core layer logic where errors are silently ignored?
>
> Looking at damos_commit_core_filters() in mm/damon/core.c, the return value
> of damos_commit_filter_arg() is not checked when adding new filters:
>
> mm/damon/core.c:damos_commit_core_filters() {
> ...
> damos_commit_filter_arg(new_filter, src_filter);
> damos_add_filter(dst, new_filter);
> ...
> }
>
> A similar pattern exists for ops filters in damos_commit_ops_filters():
>
> mm/damon/core.c:damos_commit_ops_filters() {
> ...
> if (src_filter)
> damos_commit_filter(dst_filter, src_filter);
> ...
> damos_commit_filter_arg(new_filter, src_filter);
> damos_add_filter(dst, new_filter);
> ...
> }
>
> When an invalid range is provided via sysfs, damos_commit_filter_arg()
> returns -EINVAL and aborts before copying the arguments. Because the new
> filter is allocated without zeroing its memory, the filter's union arguments
> (like addr_range) are left completely uninitialized.
>
> Since the error is ignored and damos_add_filter() is still called, won't
> this result in the scheme acting on an unpredictable memory range derived
> from uninitialized heap garbage?
Yes, I will fix those in the next spin.
>
> > } else if (filter->type == DAMOS_FILTER_TYPE_PROBE_HITS_WSUM) {
> > filter->range_min = sysfs_filter->range_min;
> > filter->range_max = sysfs_filter->range_max;
> > - if (filter->range_min > filter->range_max) {
> > - damos_destroy_filter(filter);
> > - return -EINVAL;
> > - }
> > }
> >
> > damos_add_filter(scheme, filter);
>
> --
> Sashiko AI review · https://sashiko.dev/#/patchset/20260912191807.138502-1-sj@kernel.org?part=5
Thanks,
SJ
next prev parent reply other threads:[~2026-09-12 19:43 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-12 19:17 [RFC PATCH 0/8] mm/damon: move damos filter range arguments validation to core SJ Park
2026-09-12 19:17 ` [RFC PATCH 1/8] mm/damon/sysfs-schemes: read sysfs_filter->addr_range only once SJ Park
2026-09-12 19:37 ` sashiko-bot
2026-09-12 19:18 ` [RFC PATCH 2/8] mm/damon/sysfs-schemes: read sysfs_filter->sz_range " SJ Park
2026-09-12 19:26 ` sashiko-bot
2026-09-12 19:18 ` [RFC PATCH 3/8] mm/damon/core: return an error from damos_commit_filter_arg() SJ Park
2026-09-12 19:29 ` sashiko-bot
2026-09-12 19:37 ` SJ Park
2026-09-12 19:18 ` [RFC PATCH 4/8] mm/damon/core: disallow max < min damos filter range arguments commit SJ Park
2026-09-12 19:29 ` sashiko-bot
2026-09-12 19:42 ` SJ Park
2026-09-12 19:18 ` [RFC PATCH 5/8] mm/damon/sysfs-schemes: drop centralized filter range arg validations SJ Park
2026-09-12 19:30 ` sashiko-bot
2026-09-12 19:43 ` SJ Park [this message]
2026-09-12 19:18 ` [RFC PATCH 6/8] mm/damon/sysfs-schemes: use switch-case in add_scheme_filters() SJ Park
2026-09-12 19:23 ` sashiko-bot
2026-09-12 19:18 ` [RFC PATCH 7/8] mm/damon/core-kunit: extend damos_commit_filter_for() for wrong input SJ Park
2026-09-12 19:28 ` sashiko-bot
2026-09-12 19:18 ` [RFC PATCH 8/8] mm/damon/core-kunit: test invalid damos filter commits SJ Park
2026-09-12 19:36 ` sashiko-bot
2026-09-12 19:47 ` 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=20260912194318.139608-1-sj@kernel.org \
--to=sj@kernel.org \
--cc=damon@lists.linux.dev \
--cc=sashiko-bot@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.