[PATCH 0/2] mm/damon/reclaim: fix initalization and parameter issues

[PATCH 0/2] mm/damon/reclaim: fix initalization and parameter issues

[yahia]

From: yahia ahmed <yahia.a.abdrabou@gmail.com>

This patch series addresses a potential memory
leak in the damon_reclain_init() function and a
premature destruction of ctx if there was no error
in the damon_reclaim_parameters() function

yahia (2):
  mm/damon/reclaim: fix destruction of ctx
  mm/damon/reclaim: fix potential memory leak

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

-- 
2.54.0

[PATCH 1/2] mm/damon/reclaim: fix destruction of ctx

[yahia]

From: yahia ahmed <yahia.a.abdrabou@gmail.com>

Fix the early destruction of ctx if no error was encountered
by returning 0 on success.

Signed-off-by: yahia ahmed <yahia.a.abdrabou@gmail.com>
---
 mm/damon/reclaim.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/mm/damon/reclaim.c b/mm/damon/reclaim.c
index ce4499cf4b8b..15bc06ae7505 100644
--- a/mm/damon/reclaim.c
+++ b/mm/damon/reclaim.c
@@ -268,6 +268,9 @@ static int damon_reclaim_apply_parameters(void)
 	if (err)
 		goto out;
 	err = damon_commit_ctx(ctx, param_ctx);
+
+	if (!err)
+		return 0;
 out:
 	damon_destroy_ctx(param_ctx);
 	return err;
-- 
2.54.0

Re: [PATCH 1/2] mm/damon/reclaim: fix destruction of ctx

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] The patch introduces a memory leak of the temporary DAMON context (param_ctx) and its associated structures on the success path of parameter application.
--

commit 57dd2b9f42514d0ee1c739cb34a24c15b5d98865
Author: yahia ahmed <yahia.a.abdrabou@gmail.com>

mm/damon/reclaim: fix destruction of ctx

This commit attempts to fix what is perceived as an early destruction of
the DAMON context by returning directly on success.

> diff --git a/mm/damon/reclaim.c b/mm/damon/reclaim.c
> index ce4499cf4b8b0..15bc06ae75053 100644
> --- a/mm/damon/reclaim.c
> +++ b/mm/damon/reclaim.c
> @@ -268,6 +268,9 @@ static int damon_reclaim_apply_parameters(void)
>  	if (err)
>  		goto out;
>  	err = damon_commit_ctx(ctx, param_ctx);
> +
> +	if (!err)
> +		return 0;

[Severity: High]
Does this early return cause a memory leak of the temporary context?

In damon_reclaim_apply_parameters(), param_ctx is allocated as a temporary
context to construct new targets, schemes, quotas, and filters. The call
to damon_commit_ctx() duplicates these structures into the global context
rather than taking ownership of the pointers.

Because param_ctx is temporary and its contents are copied, it needs to be
destroyed unconditionally. Skipping damon_destroy_ctx(param_ctx) on the
success path leaves the temporary param_ctx and all its attached structures
leaked on every successful parameter application.

>  out:
>  	damon_destroy_ctx(param_ctx);
>  	return err;

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

[PATCH 2/2] mm/damon/reclaim: fix potential memory leak

[yahia]

From: yahia ahmed <yahia.a.abdrabou@gmail.com>

Fix a potential memory leak if initialization encounters
an error, ctx won't be destroyed.

Signed-off-by: yahia ahmed <yahia.a.abdrabou@gmail.com>
---
 mm/damon/reclaim.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/mm/damon/reclaim.c b/mm/damon/reclaim.c
index 15bc06ae7505..dfe52717d92c 100644
--- a/mm/damon/reclaim.c
+++ b/mm/damon/reclaim.c
@@ -481,6 +481,10 @@ static int __init damon_reclaim_init(void)
 out:
 	if (err && enabled)
 		enabled = false;
+
+	/* Prevent potenial memory leakage */
+	if (err && ctx)
+		damon_destroy_ctx(ctx);
 	return err;
 }
 
-- 
2.54.0

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

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:

New issues:
- [Critical] The patch attempts to fix a memory leak by destroying the global `ctx` pointer on the error path, but fails to set it to `NULL`, leaving a dangling pointer that causes deterministic Use-After-Free vulnerabilities upon any sysfs interaction.

Pre-existing issues:
- [High] Pre-existing memory leak of `param_ctx` and its associated components when `damon_reclaim_apply_parameters()` succeeds.
--

commit 87008af2e1842854e4e34be35814335307b60672
Author: yahia ahmed <yahia.a.abdrabou@gmail.com>

mm/damon/reclaim: fix potential memory leak

Fix a potential memory leak if initialization encounters
an error, ctx won't be destroyed.

> diff --git a/mm/damon/reclaim.c b/mm/damon/reclaim.c
> index 15bc06ae75053..dfe52717d92cf 100644
> --- a/mm/damon/reclaim.c
> +++ b/mm/damon/reclaim.c
> @@ -481,6 +481,10 @@ static int __init damon_reclaim_init(void)
>  out:
>  	if (err && enabled)
>  		enabled = false;
> +
> +	/* Prevent potenial memory leakage */
> +	if (err && ctx)
> +		damon_destroy_ctx(ctx);

[Severity: Critical]
Does this leave a dangling pointer in the global ctx variable?

Because ctx is global, if it is freed here but not set to NULL, sysfs
callbacks like damon_reclaim_enabled() will bypass their safety checks:

mm/damon/reclaim.c:damon_reclaim_enabled() {
	if (!ctx)
		return false;
	return damon_is_running(ctx);
}

This would pass the freed context to damon_is_running(), which blindly
acquires the mutex:

mm/damon/core.c:damon_is_running() {
	...
	mutex_lock(&ctx->kdamond_lock);
	...
}

Can this trigger a use-after-free when sysfs parameters are accessed after
initialization fails?

>  	return err;
>  }

[Severity: High]
This is a pre-existing issue, but does damon_reclaim_apply_parameters() leak
param_ctx on the success path?

In mm/damon/reclaim.c:damon_reclaim_apply_parameters():

	err = damon_commit_ctx(ctx, param_ctx);

	if (!err)
		return 0;
out:
	damon_destroy_ctx(param_ctx);
	return err;

Since damon_commit_ctx() copies components and does not take ownership of
param_ctx, returning 0 directly without destroying param_ctx appears to leak
the locally allocated context and its attached components.

Could this lead to memory exhaustion if parameters are successfully applied
multiple times?

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

Re: [PATCH 0/2] mm/damon/reclaim: fix initalization and parameter issues

[SeongJae Park]

On Sat, 20 Jun 2026 02:46:04 +0300 yahia <yahia.a.abdrabou@gmail.com> wrote:

> From: yahia ahmed <yahia.a.abdrabou@gmail.com>
> 
> This patch series addresses a potential memory
> leak in the damon_reclain_init() function and a
> premature destruction of ctx if there was no error
> in the damon_reclaim_parameters() function
> 
> yahia (2):
>   mm/damon/reclaim: fix destruction of ctx
>   mm/damon/reclaim: fix potential memory leak

Looks both patches are unnecessary to me.  Could you please explain the issues
in detail, and if I'm wrong?


Thanks,
SJ

[...]

[PATCH v2 0/1] fix initialization and parameter issues

[yahia]

From: yahia ahmed <yahia.a.abdrabou@gmail.com>

Fixed a potential memory leak by removing the
early return to let the function continue with
out and set the ctx variable to NULL to prevent
a use after free, In damon_reclaim_init() function
if an error is returned, the ctx variable is never
freed.
~~~
Changes in v2:
- Remove early return
- Set ctx to NULL to avoid a use after free
- Fix typo

yahia (1):
  mm/damon/reclaim: fix potential memory leak

 mm/damon/reclaim.c | 5 +++++
 1 file changed, 5 insertions(+)

-- 
2.54.0

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

[yahia]

Signed-off-by: yahia <yahia.a.abdrabou@gmail.com>
---
 mm/damon/reclaim.c | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/mm/damon/reclaim.c b/mm/damon/reclaim.c
index ce4499cf4b8b..6601b08996c6 100644
--- a/mm/damon/reclaim.c
+++ b/mm/damon/reclaim.c
@@ -478,6 +478,11 @@ static int __init damon_reclaim_init(void)
 out:
 	if (err && enabled)
 		enabled = false;
+
+	if (err && ctx) {
+		damon_destroy_ctx(ctx);
+		ctx = NULL;
+	}
 	return err;
 }
 
-- 
2.54.0

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

[sashiko-bot]

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

[PATCH v3] mm/damon/reclaim: fix potential memory leak

[yahia]

From: yahia ahmed <yahia.a.abdrabou@gmail.com>

Fix a potential race condition by locking the ctx
then using damon_stop() to eliminate the thread then
destroy ctx.

Signed-off-by: yahia ahmed <yahia.a.abdrabou@gmail.com>
v3:
- Add a mutex lock to prevent possible race condition
- Stop the kdamond thread before destroying ctx
v2:
- Remove early return
- Set ctx to NULL to avoid a use after free
- Fix typo
---
 mm/damon/reclaim.c | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/mm/damon/reclaim.c b/mm/damon/reclaim.c
index 6601b08996c6..ec5558b7da41 100644
--- a/mm/damon/reclaim.c
+++ b/mm/damon/reclaim.c
@@ -480,6 +480,15 @@ static int __init damon_reclaim_init(void)
 		enabled = false;
 
 	if (err && ctx) {
+		/* Hold a lock and stop the thread to prevent a possible race condition */
+		mutex_lock(&ctx->kdamond_lock);
+
+		if (ctx->kdamond) {
+			mutex_unlock(&ctx->kdamond_lock);
+			damon_stop(ctx);
+		} else {
+			mutex_unlock(&ctx->kdamond_lock);
+		}
 		damon_destroy_ctx(ctx);
 		ctx = NULL;
 	}
-- 
2.54.0

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

[SeongJae Park]

Hello Yahia,


Please answer my question [1] to the v1 of this patch, before sending new
version of patches.  I will not review your patch before the discussion on your
v1 is finished.

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


Thanks,
SJ

[...]

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

[yahia]

Hi SJ,

Regarding you question in v1, This patch
addresses a potential memory leak in the
out path, ctx is never destroyed during exit
thus creating a potential memory leak.

Best regards,
Yahia

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

[SeongJae Park]

On Sat, 20 Jun 2026 19:50:55 +0300 yahia <yahia.a.abdrabou@gmail.com> wrote:

> Hi SJ,
> 
> Regarding you question in v1, This patch
> addresses a potential memory leak in the
> out path, ctx is never destroyed during exit
> thus creating a potential memory leak.

It is kept in the memory by the design.  It will be destroyed when the user
enables DAMON_RECLAIM later.  So, unfortunately I don't think this patch is
needed.  Please correct me if I'm wrong.

Also, I'd recommend you to thoroughly read and follow the patch submission
guide [1], if you didn't have a chance to read it yet.

[1] https://docs.kernel.org/process/submitting-patches.html


Thanks,
SJ

[...]

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

[yahia]

Hi SJ,

Thank you for your clarification
on the design intentions.

Best regards,
Yahia