Re: [RFC PATCH v2 1/2] samples/damon/mtier: error out for zero quota goal target values

[SJ Park <sj@kernel.org>]

On Sun, 02 Aug 2026 16:32:38 +0000 sashiko-bot@kernel.org wrote:

> Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
> 
> New issues:
> - [Low] The newly added comment incorrectly refers to `damos_quota_store()` instead of `damos_quota_score()`.
> 
> Pre-existing issues:
> - [High] This problem wasn't introduced by this patch, but the division-by-zero vulnerability is only patched at the module boundary in `mtier.c`. The unvalidated core API (`damos_new_quota_goal` and `damos_quota_score`) remains vulnerable and is still exploitable via other DAMON components. For instance, in `mm/damon/lru_sort.c`, an unchecked `active_mem_bp` module parameter can be set via sysfs such that it evaluates to 0, causing a kernel panic.
> --
> 
> --- Patch [1]: [RFC PATCH v2 1/2] samples/damon/mtier: error out for zero quota goal target values ---
> commit a29006e1d33ea981b557928c622fb8487e53dbc8
> Author: SJ Park <sj@kernel.org>
> samples/damon/mtier: error out for zero quota goal target values
> 
> This commit prevents a division-by-zero exception in damos_quota_score() by
> returning an error when users try to start DAMON with zero values for the
> node0_mem_used_bp or node0_mem_free_bp parameters.
> 
> Link: https://lore.kernel.org/20260801202657.117135-1-sj@kernel.org
> 
> > diff --git a/samples/damon/mtier.c b/samples/damon/mtier.c
> > index ac9c24b92ead8..d1123ebbfab90 100644
> > --- a/samples/damon/mtier.c
> > +++ b/samples/damon/mtier.c
> > @@ -156,6 +156,9 @@ static struct damon_ctx *damon_sample_mtier_build_ctx(bool promote)
> >  	if (!scheme)
> >  		goto free_out;
> >  	damon_set_schemes(ctx, &scheme, 1);
> > +	/* zero target value causes division by zero in damos_quota_store() */
> 
> [Severity: Low]
> This isn't a bug, but should this refer to damos_quota_score() instead of
> damos_quota_store()?

Good catch, it is a typo.  I will fix.

> 
> > +	if (!node0_mem_used_bp || !node0_mem_free_bp)
> > +		goto free_out;
> >  	quota_goal = damos_new_quota_goal(
> 
> [Severity: High]
> This isn't a bug introduced by this patch, but while this change handles the
> zero target value at the module boundary in mtier.c, does the unvalidated
> core API leave other DAMON components vulnerable?
> 
> For example, looking at damon_lru_sort_add_quota_goals() in
> mm/damon/lru_sort.c:
> 
>     goal = damos_new_quota_goal(DAMOS_QUOTA_INACTIVE_MEM_BP,
>                                 10000 - active_mem_bp + 2);
> 
> If active_mem_bp is set to 10002 via sysfs, this evaluates to 0.
> 
> Because damos_new_quota_goal() in mm/damon/core.c accepts the target_value
> without validation, this zero value propagates to damos_quota_score() where
> mult_frac() performs a division by goal->target_value.
> 
> Could this cause a division by zero exception leading to a kernel panic?
> Would it be safer to add validation directly inside damos_new_quota_goal()
> or damos_quota_score() to protect all consumers?

The next patch of this series is fixing the lru_sort bug.

> 
> >  			promote ? DAMOS_QUOTA_NODE_MEM_USED_BP :
> >  			DAMOS_QUOTA_NODE_MEM_FREE_BP,
> >  			promote ? node0_mem_used_bp : node0_mem_free_bp);
> 
> -- 
> Sashiko AI review · https://sashiko.dev/#/patchset/20260802162050.89477-1-sj@kernel.org?part=1


Thanks,
SJ