Re: [RFC PATCH v2 2/8] mm/damon/core: commit hugepage_size type damon filter

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] Memory leak of newly allocated `damon_filter` on the error path in `damon_commit_filters()`.
--

commit 5bd56b851690ccc1ea59e5d967224bde8e275c2a
Author: SJ Park <sj@kernel.org>

mm/damon/core: commit hugepage_size type damon filter

Extend data attribute probe filters commit logic for the new hugepage_size
filter type. This updates the size range fields of the commit destination
filter struct and validates the given range.

> diff --git a/mm/damon/core.c b/mm/damon/core.c
> index 0c98f7e267d07..ecfe99450e5f0 100644
> --- a/mm/damon/core.c
> +++ b/mm/damon/core.c
[ ... ]
> @@ -1838,6 +1848,12 @@ static int damon_commit_filters(struct damon_probe *dst,
>  		case DAMON_FILTER_TYPE_MEMCG:
>  			new_filter->memcg_id = src_filter->memcg_id;
>  			break;
> +		case DAMON_FILTER_TYPE_HUGEPAGE_SIZE:
> +			if (src_filter->range_max < src_filter->range_min)
> +				return -EINVAL;

[Severity: Medium]
Does this error path leak the newly allocated new_filter?

It looks like damon_commit_filters() returns early here without adding
new_filter to the destination list or freeing it. Since this is reachable
via the sysfs interface when a user configures a filter with a minimum
larger than the maximum, can this cause a memory leak on invalid input?

> +			new_filter->range_min = src_filter->range_min;
> +			new_filter->range_max = src_filter->range_max;
> +			break;
>  		default:
>  			break;
>  		}

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