[BUG] mm/damon/core: dangling walk_control pointer in damos_walk() on inactive context

[BUG] mm/damon/core: dangling walk_control pointer in damos_walk() on inactive context

[Raul Pazemecxas De Andrade]

Hi,

I found a bug in damos_walk() that leaves a dangling walk_control
pointer when called on an inactive context. The pattern is
structurally identical to the bug fixed in commit f9132fbc2e83
("mm/damon/core: remove call_control in inactive contexts") for
damon_call().

Description
-----------

damos_walk() sets ctx->walk_control to point to a caller-provided
stack-allocated control structure (core.c line 1560), then checks
if the DAMON context is running (line 1562). If the context is
inactive, it returns -EINVAL (line 1563) WITHOUT clearing
ctx->walk_control back to NULL.

This leaves a dangling pointer. Subsequent damos_walk() calls see
the non-NULL stale pointer and return -EBUSY, permanently locking
the DAMOS tried_regions interface.

Affected versions
-----------------

Introduced in: commit bf0eaba0ff9c ("mm/damon/core: implement damos_walk()")
First affected release: v6.14-rc1
Affected stable releases: v6.14, v6.15, v6.16, v6.17, v6.18, v6.19
Tested on: 6.19.0 (commit ca4ee40bf13d, QEMU/KVM x86_64)
Current mainline: UNFIXED

Reproduction (confirmed on 6.19.0, CONFIG_DAMON=y CONFIG_DAMON_SYSFS=y)
------------------------------------------------------------------------

  DAMON=/sys/kernel/mm/damon/admin/kdamonds

  # Setup context with scheme
  echo 1 > $DAMON/nr_kdamonds
  echo 1 > $DAMON/0/contexts/nr_contexts
  echo vaddr > $DAMON/0/contexts/0/operations
  echo 1 > $DAMON/0/contexts/0/targets/nr_targets
  echo $$ > $DAMON/0/contexts/0/targets/0/pid_target
  echo 1 > $DAMON/0/contexts/0/schemes/nr_schemes
  echo stat > $DAMON/0/contexts/0/schemes/0/action

  # Start then stop (ctx stays allocated per sysfs design)
  echo on > $DAMON/0/state
  sleep 1
  echo off > $DAMON/0/state
  sleep 1

  # Trigger bug: damos_walk() on inactive context
  echo "update_schemes_tried_regions" > $DAMON/0/state
  # Returns -EINVAL, walk_control left dangling

  # Confirm: second call gets -EBUSY (dangling pointer != NULL)
  echo "update_schemes_tried_regions" > $DAMON/0/state
  # Returns -EBUSY -- interface permanently locked

Tested output
-------------

  First call:  -EINVAL (Invalid argument)
  Second call: -EBUSY (Device or resource busy) <-- BUG confirmed

Root cause
----------

Commit bf0eaba0ff9c ("mm/damon/core: implement damos_walk()")
introduced this function without cleanup on the -EINVAL error path.

The sibling function damon_call() had the exact same bug and was
fixed in f9132fbc2e83 by adding damon_call_handle_inactive_ctx()
which removes the control object when the context is inactive.
damos_walk() has no equivalent cleanup.

Impact
------

1. PERMANENT LOCKUP: After on->off->update_schemes_tried_regions,
   all future tried_regions queries return -EBUSY forever until
   the DAMON context is destroyed.

2. DANGLING POINTER: ctx->walk_control points to freed stack memory.
   The struct damos_walk_control contains a function pointer
   (walk_fn). If any DAMON API consumer reuses the same ctx after
   damos_walk() returns -EINVAL and kdamond is restarted, it would
   dereference the dangling pointer in damos_walk_call_walk()
   (which calls control->walk_fn) or damos_walk_cancel().

Reported-by: Raul <raul_pazemecxas@hotmail.com>

Best regards,
Raul

Re: [BUG] mm/damon/core: dangling walk_control pointer in damos_walk() on inactive context

[Greg KH]

On Mon, Feb 16, 2026 at 03:34:44PM +0000, Raul Pazemecxas De Andrade wrote:
> Root cause
> ----------
> 
> Commit bf0eaba0ff9c ("mm/damon/core: implement damos_walk()")
> introduced this function without cleanup on the -EINVAL error path.
> 
> The sibling function damon_call() had the exact same bug and was
> fixed in f9132fbc2e83 by adding damon_call_handle_inactive_ctx()
> which removes the control object when the context is inactive.
> damos_walk() has no equivalent cleanup.

Can you submit a patch to resolve this to get credit for fixing the bug?

thanks,

greg k-h

RE: [PATCH] mm/damon/core: dangling walk_control pointer in damos_walk() on inactive context

[Raul Pazemecxas De Andrade]

[-- Attachment #1: Type: text/plain, Size: 3768 bytes --]

From 7d82f231f99949d041045789d3ed912ad7e25546 Mon Sep 17 00:00:00 2001
From: Raul Pazemecxas De Andrade <raul_pazemecxas@hotmail.com>
Date: Mon, 16 Feb 2026 13:06:04 -0300
Subject: [PATCH] mm/damon/core: clear walk_control on inactive context in
 damos_walk()

damos_walk() sets ctx->walk_control to the caller-provided control
structure before checking whether the context is running. If the context
is inactive (damon_is_running() returns false), the function returns
-EINVAL without clearing ctx->walk_control. This leaves a dangling
pointer to a stack-allocated structure that will be freed when the
caller returns.

This is structurally identical to the bug fixed in commit f9132fbc2e83
("mm/damon/core: remove call_control in inactive contexts") for
damon_call(), which had the same pattern of linking a control object
and returning an error without unlinking it.

The dangling walk_control pointer can cause:
1. Use-after-free if the context is later started and kdamond
   dereferences ctx->walk_control (e.g., in damos_walk_cancel()
   which writes to control->canceled and calls complete())
2. Permanent -EBUSY from subsequent damos_walk() calls, since the
   stale pointer is non-NULL

Fix this by clearing ctx->walk_control under walk_control_lock before
returning -EINVAL, mirroring the fix pattern from f9132fbc2e83.

Reported-by: Raul Pazemecxas De Andrade <raul_pazemecxas@hotmail.com>
Fixes: bf0eaba0ff9c ("mm/damon/core: implement damos_walk()")
Cc: stable@vger.kernel.org
Signed-off-by: Raul Pazemecxas De Andrade <raul_pazemecxas@hotmail.com>
---
 mm/damon/core.c | 7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/mm/damon/core.c b/mm/damon/core.c
index 5e2724a4f..fb00879af 100644
--- a/mm/damon/core.c
+++ b/mm/damon/core.c
@@ -1559,8 +1559,13 @@ int damos_walk(struct damon_ctx *ctx, struct damos_walk_control *control)
      }
      ctx->walk_control = control;
      mutex_unlock(&ctx->walk_control_lock);
-     if (!damon_is_running(ctx))
+     if (!damon_is_running(ctx)) {
+           mutex_lock(&ctx->walk_control_lock);
+           if (ctx->walk_control == control)
+                 ctx->walk_control = NULL;
+           mutex_unlock(&ctx->walk_control_lock);
            return -EINVAL;
+     }
      wait_for_completion(&control->completion);
      if (control->canceled)
            return -ECANCELED;
--
2.51.2
________________________________
De: Greg KH <gregkh@linuxfoundation.org>
Enviadas: Segunda-feira, 16 de Fevereiro de 2026 12:52
Para: Raul Pazemecxas De Andrade <raul_pazemecxas@hotmail.com>
Cc: sj@kernel.org <sj@kernel.org>; security@kernel.org <security@kernel.org>; damon@lists.linux.dev <damon@lists.linux.dev>; linux-mm@kvack.org <linux-mm@kvack.org>; linux-kernel@vger.kernel.org <linux-kernel@vger.kernel.org>
Assunto: Re: [BUG] mm/damon/core: dangling walk_control pointer in damos_walk() on inactive context

On Mon, Feb 16, 2026 at 03:34:44PM +0000, Raul Pazemecxas De Andrade wrote:
> Root cause
> ----------
>
> Commit bf0eaba0ff9c ("mm/damon/core: implement damos_walk()")
> introduced this function without cleanup on the -EINVAL error path.
>
> The sibling function damon_call() had the exact same bug and was
> fixed in f9132fbc2e83 by adding damon_call_handle_inactive_ctx()
> which removes the control object when the context is inactive.
> damos_walk() has no equivalent cleanup.

Can you submit a patch to resolve this to get credit for fixing the bug?

thanks,

greg k-h

[-- Attachment #2: Type: text/html, Size: 12030 bytes --]

RE: [PATCH] mm/damon/core: dangling walk_control pointer in damos_walk() on inactive context

[Raul Pazemecxas De Andrade]

From 7d82f231f99949d041045789d3ed912ad7e25546 Mon Sep 17 00:00:00 2001
From: Raul Pazemecxas De Andrade <raul_pazemecxas@hotmail.com>
Date: Mon, 16 Feb 2026 13:06:04 -0300
Subject: [PATCH] mm/damon/core: clear walk_control on inactive context in
 damos_walk()

damos_walk() sets ctx->walk_control to the caller-provided control
structure before checking whether the context is running. If the context
is inactive (damon_is_running() returns false), the function returns
-EINVAL without clearing ctx->walk_control. This leaves a dangling
pointer to a stack-allocated structure that will be freed when the
caller returns.

This is structurally identical to the bug fixed in commit f9132fbc2e83
("mm/damon/core: remove call_control in inactive contexts") for
damon_call(), which had the same pattern of linking a control object
and returning an error without unlinking it.

The dangling walk_control pointer can cause:
1. Use-after-free if the context is later started and kdamond
   dereferences ctx->walk_control (e.g., in damos_walk_cancel()
   which writes to control->canceled and calls complete())
2. Permanent -EBUSY from subsequent damos_walk() calls, since the
   stale pointer is non-NULL

Fix this by clearing ctx->walk_control under walk_control_lock before
returning -EINVAL, mirroring the fix pattern from f9132fbc2e83.

Reported-by: Raul Pazemecxas De Andrade <raul_pazemecxas@hotmail.com>
Fixes: bf0eaba0ff9c ("mm/damon/core: implement damos_walk()")
Cc: stable@vger.kernel.org
Signed-off-by: Raul Pazemecxas De Andrade <raul_pazemecxas@hotmail.com>
---
 mm/damon/core.c | 7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/mm/damon/core.c b/mm/damon/core.c
index 5e2724a4f..fb00879af 100644
--- a/mm/damon/core.c
+++ b/mm/damon/core.c
@@ -1559,8 +1559,13 @@ int damos_walk(struct damon_ctx *ctx, struct damos_walk_control *control)
      }
      ctx->walk_control = control;
      mutex_unlock(&ctx->walk_control_lock);
-     if (!damon_is_running(ctx))
+     if (!damon_is_running(ctx)) {
+           mutex_lock(&ctx->walk_control_lock);
+           if (ctx->walk_control == control)
+                 ctx->walk_control = NULL;
+           mutex_unlock(&ctx->walk_control_lock);
            return -EINVAL;
+     }
      wait_for_completion(&control->completion);
      if (control->canceled)
            return -ECANCELED;
-- 
2.51.2
________________________________________
De: Greg KH <gregkh@linuxfoundation.org>
Enviadas: Segunda-feira, 16 de Fevereiro de 2026 12:52
Para: Raul Pazemecxas De Andrade <raul_pazemecxas@hotmail.com>
Cc: sj@kernel.org <sj@kernel.org>; security@kernel.org <security@kernel.org>; damon@lists.linux.dev <damon@lists.linux.dev>; linux-mm@kvack.org <linux-mm@kvack.org>; linux-kernel@vger.kernel.org <linux-kernel@vger.kernel.org>
Assunto: Re: [BUG] mm/damon/core: dangling walk_control pointer in damos_walk() on inactive context


On Mon, Feb 16, 2026 at 03:34:44PM +0000, Raul Pazemecxas De Andrade wrote:

> Root cause

> ----------

>

> Commit bf0eaba0ff9c ("mm/damon/core: implement damos_walk()")

> introduced this function without cleanup on the -EINVAL error path.

>

> The sibling function damon_call() had the exact same bug and was

> fixed in f9132fbc2e83 by adding damon_call_handle_inactive_ctx()

> which removes the control object when the context is inactive.

> damos_walk() has no equivalent cleanup.



Can you submit a patch to resolve this to get credit for fixing the bug?



thanks,



greg k-h

RE: [PATCH] mm/damon/core: dangling walk_control pointer in damos_walk() on inactive context

[SeongJae Park]

Hello Raul,

On Mon, 16 Feb 2026 16:26:22 +0000 Raul Pazemecxas De Andrade <raul_pazemecxas@hotmail.com> wrote:

> From 7d82f231f99949d041045789d3ed912ad7e25546 Mon Sep 17 00:00:00 2001
> From: Raul Pazemecxas De Andrade <raul_pazemecxas@hotmail.com>
> Date: Mon, 16 Feb 2026 13:06:04 -0300
> Subject: [PATCH] mm/damon/core: clear walk_control on inactive context in
>  damos_walk()

Seems you copy-pasted this patch on your email body.  It is more usual to send
the patch as a complete new mail thread, using 'git send-email'.  Please
consider doing so if you send a patch again, next time.

> 
> damos_walk() sets ctx->walk_control to the caller-provided control
> structure before checking whether the context is running. If the context
> is inactive (damon_is_running() returns false), the function returns
> -EINVAL without clearing ctx->walk_control. This leaves a dangling
> pointer to a stack-allocated structure that will be freed when the
> caller returns.

Nice catch!

> 
> This is structurally identical to the bug fixed in commit f9132fbc2e83
> ("mm/damon/core: remove call_control in inactive contexts") for
> damon_call(), which had the same pattern of linking a control object
> and returning an error without unlinking it.

Correct.  Nonetheless, the user impact is prettry trivial compared to the
damon_call() bug.  Let me explain why I think so below.

> 
> The dangling walk_control pointer can cause:
> 1. Use-after-free if the context is later started and kdamond
>    dereferences ctx->walk_control (e.g., in damos_walk_cancel()
>    which writes to control->canceled and calls complete())

But, there is no such use case to my understanding.  DAMON sysfs interface is
the only damos_walk() user.  And when a user asks it to turn DAMON on with a
context that was used before and now stopped, it does not use the damon_ctx
object that was used before.  Instead, it deallocates the damon_ctx object that
was used before, allocates a new damon_ctx object, and use the new one.  The
new one doesn't have the stale pointer, so no real issue happens.  Please let
me know if I'm missing something.

So this is a good theory for potential future bugs.  Nonetheless, this is not
what can happen right now in the real world.  I agree the pointer is better to
be cleared as this patch suggests, to reduce such potential future risks.

> 2. Permanent -EBUSY from subsequent damos_walk() calls, since the
>    stale pointer is non-NULL

This is the real bug.  Returning -EBUSY while DAMON is turned off may confuse
users.  Nonetheless, this happens only while the DAMON context is turned off.
If you starts it again, DAMON sysfs interface starts it with newly allocated
internal damon_ctx object as I mentioned above.  The new object doesn't have
the stale pointer, so works normally.

For example, after the reproducer steps in your bug report [1], you can show
below:

    # echo on > $DAMON/0/state
    # echo "update_schemes_tried_regions" > $DAMON/0/state
    # echo $?
    # 0

Again, I think this is a real bug that could make users be confused, and
therefore better to be fixed.  Nonetheless, calling damos_walk() against
stopped DAMON context seems not a common use case.  So I think the real impact
is trivial.

> 
> Fix this by clearing ctx->walk_control under walk_control_lock before
> returning -EINVAL, mirroring the fix pattern from f9132fbc2e83.

Sounds reasonable.

> 
> Reported-by: Raul Pazemecxas De Andrade <raul_pazemecxas@hotmail.com>

Closes: https://lore.kernel.org/CPUPR80MB8171025468965E583EF2490F956CA@CPUPR80MB8171.lamprd80.prod.outlook.com

> Fixes: bf0eaba0ff9c ("mm/damon/core: implement damos_walk()")
> Cc: stable@vger.kernel.org
> Signed-off-by: Raul Pazemecxas De Andrade <raul_pazemecxas@hotmail.com>

Reviewed-by: SeongJae Park <sj@kernel.org>

> ---
>  mm/damon/core.c | 7 ++++++-
>  1 file changed, 6 insertions(+), 1 deletion(-)
> 
> diff --git a/mm/damon/core.c b/mm/damon/core.c
> index 5e2724a4f..fb00879af 100644
> --- a/mm/damon/core.c
> +++ b/mm/damon/core.c
> @@ -1559,8 +1559,13 @@ int damos_walk(struct damon_ctx *ctx, struct damos_walk_control *control)
>       }
>       ctx->walk_control = control;
>       mutex_unlock(&ctx->walk_control_lock);
> -     if (!damon_is_running(ctx))
> +     if (!damon_is_running(ctx)) {
> +           mutex_lock(&ctx->walk_control_lock);
> +           if (ctx->walk_control == control)
> +                 ctx->walk_control = NULL;
> +           mutex_unlock(&ctx->walk_control_lock);
>             return -EINVAL;
> +     }
>       wait_for_completion(&control->completion);
>       if (control->canceled)
>             return -ECANCELED;
> -- 
> 2.51.2

I also found 'git am' of this patch is not cleanly working on mm-new.  Please
consider using mm-new as the baseline [2] next time.

To ensure this is not forgotten and merged into the mainline, I added this
patch to my tree, after manually rebasing on mm-new, adding a note about the
user impact, and adding the above tags that I offered.  Unless I find something
on this patch needs to be changed, and you mind, I will post it again after the
current merge window, to make sure it goes to the mainline.  So no additional
work from your side is required.

Nonetheless, if you prefer to make a new revision of this patch and repost on
your own, please do so.

[1] https://lore.kernel.org/CPUPR80MB8171025468965E583EF2490F956CA@CPUPR80MB8171.lamprd80.prod.outlook.com
[2] https://origin.kernel.org/doc/html/latest/mm/damon/maintainer-profile.html#scm-trees
[3] https://git.kernel.org/pub/scm/linux/kernel/git/sj/damon-hack.git/tree/patches/next/mm-damon-core-clear-walk_control-on-inactive-context.patch?id=398e6f536b37de82f789d74ea93815dfcb129d99


Thanks,
SJ

[...]

RE: [PATCH] mm/damon/core: dangling walk_control pointer in damos_walk() on inactive context

[SeongJae Park]

On Mon, 16 Feb 2026 10:57:40 -0800 SeongJae Park <sj@kernel.org> wrote:

> 
> Hello Raul,
[...]
> 
> I also found 'git am' of this patch is not cleanly working on mm-new.  Please
> consider using mm-new as the baseline [2] next time.
> 
> To ensure this is not forgotten and merged into the mainline, I added this
> patch to my tree,

I forgot adding a link to it, sorry.  It is [3] on my original mail.

> after manually rebasing on mm-new, adding a note about the
> user impact, and adding the above tags that I offered.  Unless I find something
> on this patch needs to be changed, and you mind, I will post it again after the
> current merge window, to make sure it goes to the mainline.  So no additional
> work from your side is required.
> 
> Nonetheless, if you prefer to make a new revision of this patch and repost on
> your own, please do so.
> 
> [1] https://lore.kernel.org/CPUPR80MB8171025468965E583EF2490F956CA@CPUPR80MB8171.lamprd80.prod.outlook.com
> [2] https://origin.kernel.org/doc/html/latest/mm/damon/maintainer-profile.html#scm-trees
> [3] https://git.kernel.org/pub/scm/linux/kernel/git/sj/damon-hack.git/tree/patches/next/mm-damon-core-clear-walk_control-on-inactive-context.patch?id=398e6f536b37de82f789d74ea93815dfcb129d99

^^^ This one.


Thanks,
SJ

[...]

RE: [PATCH] mm/damon/core: dangling walk_control pointer in damos_walk() on inactive context

[Raul Pazemecxas De Andrade]

Hello 
SeongJae Park, in my opinion there is no need for any modifications on my part, I am extremely grateful for your help. Next time I will consider the git point informed! Thank you for all the work you've been doing on our kernel.

________________________________________
De: SeongJae Park <sj@kernel.org>
Enviado: segunda-feira, 16 de fevereiro de 2026 18:47
Para: SeongJae Park <sj@kernel.org>
Cc: Raul Pazemecxas De Andrade <raul_pazemecxas@hotmail.com>; Greg KH <gregkh@linuxfoundation.org>; security@kernel.org <security@kernel.org>; damon@lists.linux.dev <damon@lists.linux.dev>; linux-mm@kvack.org <linux-mm@kvack.org>; linux-kernel@vger.kernel.org <linux-kernel@vger.kernel.org>
Assunto: RE: [PATCH] mm/damon/core: dangling walk_control pointer in damos_walk() on inactive context
 
On Mon, 16 Feb 2026 10:57:40 -0800 SeongJae Park <sj@kernel.org> wrote:

>
> Hello Raul,
[...]
>
> I also found 'git am' of this patch is not cleanly working on mm-new.  Please
> consider using mm-new as the baseline [2] next time.
>
> To ensure this is not forgotten and merged into the mainline, I added this
> patch to my tree,

I forgot adding a link to it, sorry.  It is [3] on my original mail.

> after manually rebasing on mm-new, adding a note about the
> user impact, and adding the above tags that I offered.  Unless I find something
> on this patch needs to be changed, and you mind, I will post it again after the
> current merge window, to make sure it goes to the mainline.  So no additional
> work from your side is required.
>
> Nonetheless, if you prefer to make a new revision of this patch and repost on
> your own, please do so.
>
> [1] https://lore.kernel.org/CPUPR80MB8171025468965E583EF2490F956CA@CPUPR80MB8171.lamprd80.prod.outlook.com
> [2] https://origin.kernel.org/doc/html/latest/mm/damon/maintainer-profile.html#scm-trees
> [3] https://git.kernel.org/pub/scm/linux/kernel/git/sj/damon-hack.git/tree/patches/next/mm-damon-core-clear-walk_control-on-inactive-context.patch?id=398e6f536b37de82f789d74ea93815dfcb129d99

^^^ This one.


Thanks,
SJ

[...]

RE: [BUG] mm/damon/core: dangling walk_control pointer in damos_walk() on inactive context

[Raul Pazemecxas De Andrade]

Thanks for your attention Greg and congratulations on your work on our Kernel
________________________________________
De: Greg KH <gregkh@linuxfoundation.org>
Enviadas: Segunda-feira, 16 de Fevereiro de 2026 12:52
Para: Raul Pazemecxas De Andrade <raul_pazemecxas@hotmail.com>
Cc: sj@kernel.org <sj@kernel.org>; security@kernel.org <security@kernel.org>; damon@lists.linux.dev <damon@lists.linux.dev>; linux-mm@kvack.org <linux-mm@kvack.org>; linux-kernel@vger.kernel.org <linux-kernel@vger.kernel.org>
Assunto: Re: [BUG] mm/damon/core: dangling walk_control pointer in damos_walk() on inactive context


On Mon, Feb 16, 2026 at 03:34:44PM +0000, Raul Pazemecxas De Andrade wrote:

> Root cause

> ----------

>

> Commit bf0eaba0ff9c ("mm/damon/core: implement damos_walk()")

> introduced this function without cleanup on the -EINVAL error path.

>

> The sibling function damon_call() had the exact same bug and was

> fixed in f9132fbc2e83 by adding damon_call_handle_inactive_ctx()

> which removes the control object when the context is inactive.

> damos_walk() has no equivalent cleanup.



Can you submit a patch to resolve this to get credit for fixing the bug?



thanks,



greg k-h