All of lore.kernel.org
 help / color / mirror / Atom feed
From: SeongJae Park <sj@kernel.org>
To: sashiko-bot@kernel.org
Cc: SeongJae Park <sj@kernel.org>,
	damon@lists.linux.dev, Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [PATCH v3 3/3] mm/damon/stat: detect and use fresh enabled value
Date: Sun, 19 Apr 2026 11:19:54 -0700	[thread overview]
Message-ID: <20260419181954.11159-1-sj@kernel.org> (raw)
In-Reply-To: <20260419175120.AEC4EC2BCAF@smtp.kernel.org>

On Sun, 19 Apr 2026 17:51:20 +0000 sashiko-bot@kernel.org wrote:

> Sashiko AI review found 2 potential issue(s):
> - [Critical] Passing `enabled=Y` during module load triggers a double-start, failing initialization and causing a Use-After-Free kernel panic.
> - [High] Resource leak of `damon_stat_context` when explicitly disabling the module after an internal kdamond crash.

Both are wrong.  Please read below for more details.

> --
> 
> commit 16eae8a1bf380cdb61d4dd6b62187dd09f8ce859
> Author: SeongJae Park <sj@kernel.org>
> 
> mm/damon/stat: detect and use fresh enabled value
> 
> This commit updates the DAMON_STAT module to dynamically detect the running
> status of its kdamond thread rather than relying on a cached parameter
> value.
> 
> Link: https://lore.kernel.org/20260416040602.88665-1-sj@kernel.org
> 
> > diff --git a/mm/damon/stat.c b/mm/damon/stat.c
> > index 99ba346f9e325..3951b762cbddf 100644
> > --- a/mm/damon/stat.c
> > +++ b/mm/damon/stat.c
> [ ... ]
> > @@ -273,17 +276,23 @@ static void damon_stat_stop(void)
> >  	damon_stat_context = NULL;
> >  }
> >  
> > +static bool damon_stat_enabled(void)
> > +{
> > +	if (!damon_stat_context)
> > +		return false;
> > +	return damon_is_running(damon_stat_context);
> > +}
> > +
> >  static int damon_stat_enabled_store(
> >  		const char *val, const struct kernel_param *kp)
> >  {
> > -	bool is_enabled = enabled;
> >  	int err;
> >  
> >  	err = kstrtobool(val, &enabled);
> >  	if (err)
> >  		return err;
> >  
> > -	if (is_enabled == enabled)
> > +	if (damon_stat_enabled() == enabled)
> >  		return 0;
> 
> If kdamond terminates asynchronously (for example, due to an allocation
> failure), damon_stat_enabled() will return false.
> 
> If a user subsequently disables the module by writing 'N' to the enabled
> parameter, this condition (false == false) evaluates to true and the
> function returns 0.
> 
> Does this skip the call to damon_stat_stop() and leak the
> damon_stat_context since damon_destroy_ctx() won't be called?

I previously explained [1] it is not leaked.

> 
> >  
> >  	if (!damon_initialized())
> > @@ -293,16 +302,17 @@ static int damon_stat_enabled_store(
> >  		 */
> >  		return 0;
> >  
> > -	if (enabled) {
> > -		err = damon_stat_start();
> > -		if (err)
> > -			enabled = false;
> > -		return err;
> > -	}
> > +	if (enabled)
> > +		return damon_stat_start();
> 
> During module load via "insmod damon_stat.ko enabled=Y", parse_args() calls
> this store function. Because damon_stat_enabled() dynamically returns false
> at this point, the code proceeds to call damon_stat_start() to start the
> kdamond thread.
> 
> Shortly after, the module initialization function damon_stat_init() runs,
> sees enabled == true, and calls damon_stat_start() again. This second call
> returns -EAGAIN because the context is already running.
> 
> The module initialization then fails, causing the kernel to unload the
> module and free its memory.
> 
> Since the kdamond thread is still actively running in the background, can
> this cause a Use-After-Free when the thread accesses the freed module
> memory?
> 
> While this issue previously existed if CONFIG_DAMON_STAT_ENABLED_DEFAULT=n,
> does this patch introduce the regression for the default configuration as
> well?

DAMON_STAT is a builtin module.  Users cannot load it dynamically, and
therefore the above scenario cannot happen.

[1] https://lore.kernel.org/20260417000308.58975-1-sj@kernel.org


Thanks,
SJ

[...]

      reply	other threads:[~2026-04-19 18:20 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-04-19 16:09 [PATCH v3 0/3] mm/damon/modules: detect and use fresh status SeongJae Park
2026-04-19 16:10 ` [PATCH v3 1/3] mm/damon/reclaim: detect and use fresh enabled and kdamond_pid values SeongJae Park
2026-04-19 16:48   ` sashiko-bot
2026-04-19 16:52     ` SeongJae Park
2026-04-19 16:10 ` [PATCH v3 2/3] mm/damon/lru_sort: " SeongJae Park
2026-04-19 17:28   ` sashiko-bot
2026-04-19 18:12     ` SeongJae Park
2026-04-19 16:10 ` [PATCH v3 3/3] mm/damon/stat: detect and use fresh enabled value SeongJae Park
2026-04-19 17:51   ` sashiko-bot
2026-04-19 18:19     ` SeongJae Park [this message]

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=20260419181954.11159-1-sj@kernel.org \
    --to=sj@kernel.org \
    --cc=akpm@linux-foundation.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.