All of lore.kernel.org
 help / color / mirror / Atom feed
From: SJ Park <sj@kernel.org>
To: sashiko-bot@kernel.org
Cc: SJ Park <sj@kernel.org>, damon@lists.linux.dev
Subject: Re: [RFC PATCH v1.2 05/12] mm/damon/sysfs: remove probes number validation
Date: Wed, 29 Jul 2026 07:24:44 -0700	[thread overview]
Message-ID: <20260729142446.88564-1-sj@kernel.org> (raw)
In-Reply-To: <20260729141624.E24191F00A3F@smtp.kernel.org>

On Wed, 29 Jul 2026 14:16:24 +0000 sashiko-bot@kernel.org wrote:

> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> - [High] Removing the upper bound check on `nr_probes` allows userspace to trigger massive unbounded kobject allocations, causing soft lockups and OOM.
> --
> 
> --- Patch [5]: [RFC PATCH v1.2 05/12] mm/damon/sysfs: remove probes number validation ---
> commit a336beb0d20022011c91edc1b40bfb3902ced157
> Author: SJ Park <sj@kernel.org>
> 
> mm/damon/sysfs: remove probes number validation
> 
> DAMON sysfs interface drops the >DAMON_MAX_PROBES validation on
> nr_probes input, intending to let the core layer validate the upper
> limit instead.
> 
> > diff --git a/mm/damon/sysfs.c b/mm/damon/sysfs.c
> > index e3858ffab4b22..85dca07169c63 100644
> > --- a/mm/damon/sysfs.c
> > +++ b/mm/damon/sysfs.c
> > @@ -1234,7 +1234,7 @@ static ssize_t nr_probes_store(struct kobject *kobj,
> >  
> >  	if (err)
> >  		return err;
> > -	if (nr < 0 || nr > DAMON_MAX_PROBES)
> > +	if (nr < 0)
> >  		return -EINVAL;
> 
> [Severity: High]
> Does removing this upper bound allow userspace to trigger soft lockups or
> OOM?
> 
> If a user writes a very large value (e.g. 2,000,000) here, that unbounded
> value is passed into damon_sysfs_probes_add_dirs() and iterates this loop:
> 
> mm/damon/sysfs.c:damon_sysfs_probes_add_dirs() {
>     ...
> 	probes_arr = kmalloc_objs(*probes_arr, nr_probes,
> 				   GFP_KERNEL | __GFP_NOWARN);
> 	if (!probes_arr)
> 		return -ENOMEM;
> 	probes->probes_arr = probes_arr;
> 
> 	for (i = 0; i < nr_probes; i++) {
> 		probe = damon_sysfs_probe_alloc();
>     ...
> }
> 
> Since this loop allocates sysfs kobjects synchronously without
> cond_resched(), will this cause the system to freeze or exhaust memory
> before the DAMON core layer ever gets a chance to validate the parameters?

Sane users wouldn't do that.  We can revisit if this turns out to be a real
issue.

> 
> >  
> >  	probes = container_of(kobj, struct damon_sysfs_probes, kobj);
> 
> -- 
> Sashiko AI review · https://sashiko.dev/#/patchset/20260729140253.87753-1-sj@kernel.org?part=5


Thanks,
SJ

  reply	other threads:[~2026-07-29 14:24 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-29 14:02 [RFC PATCH v1.2 00/12] mm/damon: cleanup code, add test cases, and update guidances in docs SJ Park
2026-07-29 14:02 ` [RFC PATCH v1.2 01/12] mm/damon/core: use damon_nr_samples_per_aggr() for max merge threshold SJ Park
2026-07-29 14:02 ` [RFC PATCH v1.2 02/12] mm/damon/core: remove debug messages SJ Park
2026-07-29 14:02 ` [RFC PATCH v1.2 03/12] mm/damon/vaddr: remove a debug message SJ Park
2026-07-29 14:02 ` [RFC PATCH v1.2 04/12] mm/damon/core: validate number of probes in valid_probe_params() SJ Park
2026-07-29 14:02 ` [RFC PATCH v1.2 05/12] mm/damon/sysfs: remove probes number validation SJ Park
2026-07-29 14:16   ` sashiko-bot
2026-07-29 14:24     ` SJ Park [this message]
2026-07-29 14:02 ` [RFC PATCH v1.2 06/12] mm/damon/tests/core-kunit: extend set_regions() test for error case SJ Park
2026-07-29 14:02 ` [RFC PATCH v1.2 07/12] mm/damon/tests/core-kunit: test <=0 size damon_set_regions() inputs SJ Park
2026-07-29 14:02 ` [RFC PATCH v1.2 08/12] mm/damon/tests/core-kunit: test overlapping ranges for set_regions() SJ Park
2026-07-29 14:02 ` [RFC PATCH v1.2 09/12] mm/damon/tests/core-kunit: test damon_nr_samples_per_aggr() SJ Park
2026-07-29 14:02 ` [RFC PATCH v1.2 10/12] selftests/damon/sysfs.sh: test hugepage_mem_bp quota goal SJ Park
2026-07-29 14:02 ` [RFC PATCH v1.2 11/12] Docs/mm/damon/maintainer-profile: update AI review for Sashiko replies SJ Park
2026-07-29 14:02 ` [RFC PATCH v1.2 12/12] Docs/ABI/damon: recommend subsystem doc instead of admin-guide 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=20260729142446.88564-1-sj@kernel.org \
    --to=sj@kernel.org \
    --cc=damon@lists.linux.dev \
    --cc=sashiko-bot@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.