Re: [RFC PATCH 5/8] mm/damon/sysfs: support hugepage_size probe filter

[SJ Park <sj@kernel.org>]

On Sun, 13 Sep 2026 17:30:22 +0000 sashiko-bot@kernel.org wrote:

> Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
> 
> New issues:
> - [Medium] Missing bounds validation for hugepage_size filter in damon_sysfs_set_filters().
> 
> Pre-existing issues:
> - [High] Newly created hugepage_size filters lack range bounds initialization in damon_commit_filters(), causing the DAMON core to evaluate folios against uninitialized kernel heap memory.
> --
> 
> commit 42f3666a978b5b2934ebb23daaee8fd5163c7793
> Author: SJ Park <sj@kernel.org>
> Subject: mm/damon/sysfs: support hugepage_size probe filter
> 
> This commit extends the DAMON sysfs interface to support the hugepage_size
> probe filter. It allows users to set hugepage_size via sysfs min/max files
> and passes these arguments to the DAMON core.
> 
> > diff --git a/mm/damon/sysfs.c b/mm/damon/sysfs.c
> > index 8e8d89b8ed981..43519afb9eb7f 100644
> > --- a/mm/damon/sysfs.c
> > +++ b/mm/damon/sysfs.c
> 
> [ ... ]
> 
> > @@ -2273,6 +2277,9 @@ static int damon_sysfs_set_filters(struct damon_probe *probe,
> >  				damon_destroy_filter(filter);
> >  				return err;
> >  			}
> > +		} else if (filter->type = DAMON_FILTER_TYPE_HUGEPAGE_SIZE) {
> > +			filter->range_min = sys_filter->range_min;
> > +			filter->range_max = sys_filter->range_max;
> 
> [Severity: Medium]
> Are bounds checks needed here to ensure range_min is less than or equal to
> range_max?
> 
> Because DAMON's initial startup via damon_start() bypasses the bounds check
> in damon_commit_filter(), turning DAMON on with inverted bounds in sysfs
> silently accepts the configuration. The filter then unconditionally fails to
> match any folios, resulting in a silent functional failure instead of an
> expected -EINVAL rejection.

No.  damon_start() does test purpose commit, so the bound check is done.

> 
> [Severity: High]
> This isn't a bug introduced by this patch, but I noticed that newly created
> hugepage_size filters lack range bounds initialization in
> damon_commit_filters().
> 
> If a user configures a new hugepage_size filter via sysfs on an already
> running DAMON context and writes 'commit' to the state file, the newly
> added filter is allocated without initializing the range:
> 
> mm/damon/core.c:damon_commit_filters() {
> ...
> 		new_filter = damon_new_filter(src_filter->type,
> 				src_filter->matching, src_filter->allow);
> 		if (!new_filter)
> 			return -ENOMEM;
> 		switch (src_filter->type) {
> 		case DAMON_FILTER_TYPE_MEMCG:
> 			new_filter->memcg_id = src_filter->memcg_id;
> 			break;
> 		default:
> 			break;
> 		}
> ...
> }
> 
> Because damon_new_filter() allocates memory without zeroing, and the switch
> statement explicitly omits DAMON_FILTER_TYPE_HUGEPAGE_SIZE, range_min and
> range_max are populated with uninitialized kernel heap memory. Could this
> cause the DAMON core to evaluate folios against erratic heap garbage?

Good catch.  I will fix in the next spin.

> 
> > +		}
> >  		damon_add_filter(probe, filter);
> >  	}
> 
> -- 
> Sashiko AI review · https://sashiko.dev/#/patchset/20260913171133.102366-1-sj@kernel.org?part=5
> 


Thanks,
SJ