From: Raul Pazemecxas De Andrade <raul_pazemecxas@hotmail.com>
To: "sj@kernel.org" <sj@kernel.org>
Cc: "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>,
"security@kernel.org" <security@kernel.org>
Subject: [BUG] mm/damon/core: dangling walk_control pointer in damos_walk() on inactive context
Date: Mon, 16 Feb 2026 15:18:39 +0000 [thread overview]
Message-ID: <CPUPR80MB817114F8F409F0293D3799C1956CA@CPUPR80MB8171.lamprd80.prod.outlook.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 3190 bytes --]
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 DOS: 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 Pazemécxas <raul_pazemecxas@hotmail.com>
Best regards,
Raul
[-- Attachment #2: Type: text/html, Size: 16912 bytes --]
next reply other threads:[~2026-02-16 15:18 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-16 15:18 Raul Pazemecxas De Andrade [this message]
2026-02-16 15:34 Raul Pazemecxas De Andrade
2026-02-16 15:52 ` Greg KH
2026-02-16 16:26 ` Raul Pazemecxas De Andrade
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CPUPR80MB817114F8F409F0293D3799C1956CA@CPUPR80MB8171.lamprd80.prod.outlook.com \
--to=raul_pazemecxas@hotmail.com \
--cc=damon@lists.linux.dev \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=security@kernel.org \
--cc=sj@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox