From: sashiko-bot@kernel.org
To: "SJ Park" <sj@kernel.org>
Cc: damon@lists.linux.dev
Subject: Re: [RFC PATCH v2 1/2] samples/damon/mtier: error out for zero quota goal target values
Date: Sun, 02 Aug 2026 16:32:38 +0000 [thread overview]
Message-ID: <20260802163239.A7FFA1F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260802162050.89477-2-sj@kernel.org>
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()?
> + 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?
> 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
next prev parent reply other threads:[~2026-08-02 16:32 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-02 16:20 [RFC PATCH v2 0/2] mm/damon: avoid division by zero from damos_quota_score() SJ Park
2026-08-02 16:20 ` [RFC PATCH v2 1/2] samples/damon/mtier: error out for zero quota goal target values SJ Park
2026-08-02 16:32 ` sashiko-bot [this message]
2026-08-02 16:52 ` SJ Park
2026-08-02 16:20 ` [RFC PATCH v2 2/2] mm/damon/lru_sort: error out for >10000 active_mem_bp SJ Park
2026-08-02 16:36 ` sashiko-bot
2026-08-02 17:30 ` 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=20260802163239.A7FFA1F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=damon@lists.linux.dev \
--cc=sashiko-reviews@lists.linux.dev \
--cc=sj@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).