Re: [PATCH v2 1/1] mm/damon/reclaim: fix potential memory leak

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Critical] Use-After-Free and double-free in the DAMON reclaim target initialization error path.
--

commit 277092b38a2c2a13afa6d95d878b7d2841e91821
Author: yahia <yahia.a.abdrabou@gmail.com>

mm/damon/reclaim: fix potential memory leak

This commit attempts to fix a potential memory leak in the damon reclaim
initialization path by destroying the context if an error occurs.

> diff --git a/mm/damon/reclaim.c b/mm/damon/reclaim.c
> --- a/mm/damon/reclaim.c
> +++ b/mm/damon/reclaim.c

[ ... ]

>  	/* 'enabled' has set before this function, probably via command line */
>  	if (enabled)
>  		err = damon_reclaim_turn(true);
>  
>  out:
>  	if (err && enabled)
>  		enabled = false;
> +
> +	if (err && ctx) {
> +		damon_destroy_ctx(ctx);

[Severity: Critical]
Could this introduce a race condition with the kdamond background thread
leading to a use-after-free and double-free?

If damon_reclaim_turn(true) successfully starts the kdamond_fn thread but a
subsequent operation returns an error (such as -ECANCELED if the thread
encounters an early failure), err will be non-zero.

If that happens, kdamond_fn might be concurrently executing its own teardown
sequence:

kdamond_fn()
done:
    damon_destroy_targets(ctx);
    ...
    mutex_lock(&ctx->walk_control_lock);
    ...

If we blindly call damon_destroy_ctx(ctx) here, it frees the ctx and its
targets while the kdamond thread is still actively using and freeing them.

Should this path ensure the kdamond thread has fully stopped (perhaps
via damon_stop() or similar synchronization) before destroying the context?

> +		ctx = NULL;
> +	}
>  	return err;
>  }

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260620003557.243313-2-yahia.a.abdrabou@gmail.com?part=1