public inbox for linux-mm@kvack.org
 help / color / mirror / Atom feed
* [PATCH v2] mm/damon/stat: deallocate damon_call() failure leaking damon_ctx
@ 2026-04-02 13:44 SeongJae Park
  2026-04-02 15:23 ` (sashiko review) " SeongJae Park
  0 siblings, 1 reply; 2+ messages in thread
From: SeongJae Park @ 2026-04-02 13:44 UTC (permalink / raw)
  To: Andrew Morton; +Cc: SeongJae Park, # 6 . 17 . x, damon, linux-kernel, linux-mm

damon_stat_start() always allocates the module's damon_ctx object
(damon_stat_context).  Meanwhile, if damon_call() in the function fails,
the damon_ctx object is not deallocated.  Hence, if the damon_call() is
failed, and the user writes Y to “enabled” again, the previously
allocated damon_ctx object is leaked.

This cannot simply be fixed by deallocating the damon_ctx object when
damon_call() fails.  That's because damon_call() failure doesn't
guarantee the kdamond main function, which accesses the damon_ctx
object, is completely finished.  In other words, if damon_stat_start()
deallocates the damon_ctx object after damon_call() failure, the
not-yet-terminated kdamond could access the freed memory
(use-after-free).

Fix the leak while avoiding the use-after-free by keeping returning
damon_stat_start() without deallocating the damon_ctx object after
damon_call() failure, but deallocating it when the function is invoked
again and the kdamond is completely terminated.  If the kdamond is not
yet terminated, simply return -EAGAIN, as the kdamond will soon be
terminated.

The issue was discovered [1] by sashiko.

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

Fixes: 405f61996d9d ("mm/damon/stat: use damon_call() repeat mode instead of damon_callback")
Cc: <stable@vger.kernel.org> # 6.17.x
Signed-off-by: SeongJae Park <sj@kernel.org>
---
Changes from RFC
(https://lore.kernel.org/20260402045928.71170-1-sj@kernel.org)
- Drop RFC tag again.
- sashiko didn't find any real issue on this version.
Changes from v1
(https://lore.kernel.org/20260402010457.66860-1-sj@kernel.org)
- Avoid sashiko-discovered use-after-free.
- Add RFC tag.

 mm/damon/stat.c | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/mm/damon/stat.c b/mm/damon/stat.c
index 5a742fc157e4..99ba346f9e32 100644
--- a/mm/damon/stat.c
+++ b/mm/damon/stat.c
@@ -245,6 +245,12 @@ static int damon_stat_start(void)
 {
 	int err;
 
+	if (damon_stat_context) {
+		if (damon_is_running(damon_stat_context))
+			return -EAGAIN;
+		damon_destroy_ctx(damon_stat_context);
+	}
+
 	damon_stat_context = damon_stat_build_ctx();
 	if (!damon_stat_context)
 		return -ENOMEM;
@@ -264,6 +270,7 @@ static void damon_stat_stop(void)
 {
 	damon_stop(&damon_stat_context, 1);
 	damon_destroy_ctx(damon_stat_context);
+	damon_stat_context = NULL;
 }
 
 static int damon_stat_enabled_store(

base-commit: 4fd04f750d79667937931314ed64c9d79b0d82ef
-- 
2.47.3


^ permalink raw reply related	[flat|nested] 2+ messages in thread

* Re: (sashiko review) [PATCH v2] mm/damon/stat: deallocate damon_call() failure leaking damon_ctx
  2026-04-02 13:44 [PATCH v2] mm/damon/stat: deallocate damon_call() failure leaking damon_ctx SeongJae Park
@ 2026-04-02 15:23 ` SeongJae Park
  0 siblings, 0 replies; 2+ messages in thread
From: SeongJae Park @ 2026-04-02 15:23 UTC (permalink / raw)
  To: SeongJae Park; +Cc: Andrew Morton, damon, linux-kernel, linux-mm

- stable@, as it seems this is not really need to be shared there.

TL; DR: sashiko didn't find any real issue.

Forwarding Sashiko review in a reply form with my inline comments, for doing
detailed discussions via mails if needed.

> # review url: https://sashiko.dev/#/patchset/20260402134418.74121-1-sj@kernel.org
> # start of sashiko.dev inline review
> commit f956e734cbf12d26893e0ce6fe09667b1ba0ca51
> Author: SeongJae Park <sj@kernel.org>
> 
> mm/damon/stat: deallocate damon_call() failure leaking damon_ctx
> 
> This commit attempts to fix a memory leak and avoid a use-after-free
> by deferring the deallocation of the damon_ctx object when damon_call()
> fails, cleaning it up on the next invocation instead.
> 
> Link: https://lore.kernel.org/20260401012428.86694-1-sj@kernel.org
> 
> > diff --git a/mm/damon/stat.c b/mm/damon/stat.c
> > index 30aeb2c207ec3..b1011a7a2f291 100644
> > --- a/mm/damon/stat.c
> > +++ b/mm/damon/stat.c
> > @@ -245,6 +245,12 @@ static int damon_stat_start(void)
> >  {
> >  	int err;
> >  
> > +	if (damon_stat_context) {
> > +		if (damon_is_running(damon_stat_context))
> > +			return -EAGAIN;
> > +		damon_destroy_ctx(damon_stat_context);
> > +	}
> > +
> >  	damon_stat_context = damon_stat_build_ctx();
> 
> [ ... ]
> 
> The commit message notes that deallocating damon_stat_context immediately 
> after a damon_call() failure leads to a use-after-free if kdamond is still 
> running. 
> 
> However, it appears the immediate deallocation in the error path was 
> left intact at the end of damon_stat_start():
> 
> 	err = damon_call(damon_stat_context, &call_control);
> 	if (err) {
> 		damon_destroy_ctx(damon_stat_context);
> 		damon_stat_context = NULL;
> 	}
> 	return err;
> 
> Since damon_stat_context is still immediately destroyed and set to NULL 
> when damon_call() fails, does this leave the use-after-free issue 
> unresolved?
> 
> Additionally, because it is set to NULL, the new deferred cleanup logic 
> added at the top of the function will evaluate to false on the next 
> invocation. Should the immediate deallocation block be removed to allow
> the new cleanup logic to handle it?

Seems sashiko is saying so because sashiko applied the patch on one of mm.git
trees that having the v1 of this patch.  I asked Andrew to drop the v1, so
sashiko's claim shouldn't be a real issue.

> 
> 
> # end of sashiko.dev inline review
> # review url: https://sashiko.dev/#/patchset/20260402134418.74121-1-sj@kernel.org


Thanks,
SJ

[...]


^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2026-04-02 15:23 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-04-02 13:44 [PATCH v2] mm/damon/stat: deallocate damon_call() failure leaking damon_ctx SeongJae Park
2026-04-02 15:23 ` (sashiko review) " SeongJae Park

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox