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

[sashiko-bot@kernel.org]

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.

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

> +		}
>  		damon_add_filter(probe, filter);
>  	}

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260913171133.102366-1-sj@kernel.org?part=5