Re: (sashiko review) [PATCH v2] mm/damon/stat: deallocate damon_call() failure leaking damon_ctx

[SeongJae Park]

- 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@xxxxxxxxxx
> # start of sashiko.dev inline review
> commit f956e734cbf12d26893e0ce6fe09667b1ba0ca51
> Author: SeongJae Park <sj@xxxxxxxxxx>
> 
> 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@xxxxxxxxxx
> 
> > 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@xxxxxxxxxx


Thanks,
SJ

[...]