[RFC PATCH 0/2] mm/damon/sysfs-schemes: fix use-after-free for [memcg_]path

[RFC PATCH 0/2] mm/damon/sysfs-schemes: fix use-after-free for [memcg_]path

[SeongJae Park]

Reads of 'path' and 'memcg_path' files in DAMON sysfs interface could
race with their writes, results in use-after-free.  Fix those.

SeongJae Park (2):
  mm/damon/sysfs-schemes: protect memcg_path kfree() with
    damon_sysfs_lock
  mm/damon/sysfs-schemes: protect path kfree() with damon_sysfs_lock

 mm/damon/sysfs-schemes.c | 24 ++++++++++++++++++++++--
 1 file changed, 22 insertions(+), 2 deletions(-)


base-commit: 0d45806f3a75bf53e59475b0e56be324f650ab09
-- 
2.47.3

[RFC PATCH 1/2] mm/damon/sysfs-schemes: protect memcg_path kfree() with damon_sysfs_lock

[SeongJae Park]

damon_sysfs_scheme_filter->mmecg_path can be read and written by users,
via DAMON sysfs memcg_path file.  It can also be indirectly read, for
the parameters {on,off}line committing to DAMON.  The reads for
parameters committing are protected by damon_sysfs_lock to avoid the
sysfs files being destroyed while any of the parameters are being read.
But the user-driven direct reads and writes are not protected by any
lock, while the write is deallocating the memcg_path-pointing buffer. As
a result, the readers could read the already freed buffer
(user-after-free).  Note that the user-reads don't race when the same
open file is used by the writer, due to kernfs's open file locking.
Nonetheless, doing the reads and writes with separate open files would
be common.  Fix it by protecting both the user-direct reads and writes
with damon_sysfs_lock.

Fixes: 4f489fe6afb3 ("mm/damon/sysfs-schemes: free old damon_sysfs_scheme_filter->memcg_path on write")
Cc: <stable@vger.kernel.org> # 6.16.x
Co-developed-by: Junxi Qian <qjx1298677004@gmail.com>
Signed-off-by: Junxi Qian <qjx1298677004@gmail.com>
Signed-off-by: SeongJae Park <sj@kernel.org>
---
 mm/damon/sysfs-schemes.c | 12 +++++++++++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/mm/damon/sysfs-schemes.c b/mm/damon/sysfs-schemes.c
index 5186966dafb35..8d32a20531d49 100644
--- a/mm/damon/sysfs-schemes.c
+++ b/mm/damon/sysfs-schemes.c
@@ -533,9 +533,14 @@ static ssize_t memcg_path_show(struct kobject *kobj,
 {
 	struct damon_sysfs_scheme_filter *filter = container_of(kobj,
 			struct damon_sysfs_scheme_filter, kobj);
+	int len;
 
-	return sysfs_emit(buf, "%s\n",
+	if (!mutex_trylock(&damon_sysfs_lock))
+		return -EBUSY;
+	len = sysfs_emit(buf, "%s\n",
 			filter->memcg_path ? filter->memcg_path : "");
+	mutex_unlock(&damon_sysfs_lock);
+	return len;
 }
 
 static ssize_t memcg_path_store(struct kobject *kobj,
@@ -550,8 +555,13 @@ static ssize_t memcg_path_store(struct kobject *kobj,
 		return -ENOMEM;
 
 	strscpy(path, buf, count + 1);
+	if (!mutex_trylock(&damon_sysfs_lock)) {
+		kfree(path);
+		return -EBUSY;
+	}
 	kfree(filter->memcg_path);
 	filter->memcg_path = path;
+	mutex_unlock(&damon_sysfs_lock);
 	return count;
 }
 
-- 
2.47.3

[RFC PATCH 2/2] mm/damon/sysfs-schemes: protect path kfree() with damon_sysfs_lock

[SeongJae Park]

damon_sysfs_quot_goal->path can be read and written by users, via DAMON
sysfs memcg_path file.  It can also be indirectly read, for the
parameters {on,off}line committing to DAMON.  The reads for parameters
committing are protected by damon_sysfs_lock to avoid the sysfs files
being destroyed while any of the parameters are being read.  But the
user-driven direct reads and writes are not protected by any lock, while
the write is deallocating the path-pointing buffer. As a result, the
readers could read the already freed buffer (user-after-free).  Note
that the user-reads don't race when the same open file is used by the
writer, due to kernfs's open file locking.  Nonetheless, doing the reads
and writes with separate open files would be common.  Fix it by
protecting both the user-direct reads and writes with damon_sysfs_lock.

Fixes: c41e253a411e ("mm/damon/sysfs-schemes: implement path file under quota goal directory")
Cc: <stable@vger.kernel.org> # 6.19.x
Co-developed-by: Junxi Qian <qjx1298677004@gmail.com>
Signed-off-by: Junxi Qian <qjx1298677004@gmail.com>
Signed-off-by: SeongJae Park <sj@kernel.org>
---
 mm/damon/sysfs-schemes.c | 12 +++++++++++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/mm/damon/sysfs-schemes.c b/mm/damon/sysfs-schemes.c
index 8d32a20531d49..245d63808411a 100644
--- a/mm/damon/sysfs-schemes.c
+++ b/mm/damon/sysfs-schemes.c
@@ -1197,8 +1197,13 @@ static ssize_t path_show(struct kobject *kobj,
 {
 	struct damos_sysfs_quota_goal *goal = container_of(kobj,
 			struct damos_sysfs_quota_goal, kobj);
+	int len;
 
-	return sysfs_emit(buf, "%s\n", goal->path ? goal->path : "");
+	if (!mutex_trylock(&damon_sysfs_lock))
+		return -EBUSY;
+	len = sysfs_emit(buf, "%s\n", goal->path ? goal->path : "");
+	mutex_unlock(&damon_sysfs_lock);
+	return len;
 }
 
 static ssize_t path_store(struct kobject *kobj,
@@ -1213,8 +1218,13 @@ static ssize_t path_store(struct kobject *kobj,
 		return -ENOMEM;
 
 	strscpy(path, buf, count + 1);
+	if (!mutex_trylock(&damon_sysfs_lock)) {
+		kfree(path);
+		return -EBUSY;
+	}
 	kfree(goal->path);
 	goal->path = path;
+	mutex_unlock(&damon_sysfs_lock);
 	return count;
 }
 
-- 
2.47.3

Re: [RFC PATCH 0/2] mm/damon/sysfs-schemes: fix use-after-free for [memcg_]path

[SeongJae Park]

On Wed, 22 Apr 2026 07:34:59 -0700 SeongJae Park <sj@kernel.org> wrote:

> Reads of 'path' and 'memcg_path' files in DAMON sysfs interface could
> race with their writes, results in use-after-free.  Fix those.

Forgot adding change log, sorry.

Changes from v2
- v2: https://lore.kernel.org/20260420125405.362137-1-qjx1298677004@gmail.com
- Split patch for individual fixes commits.
- Hand-off authorship to SJ, give Co-developed-by: to Junxi.
- Use mutex_trylock() instead of mutex_lock().
- Add RFC tag for Sashiko review round.
- Wordsmith commit messages.
Changes from v1
- v1: https://lore.kernel.org/20260420085332.178473-1-qjx1298677004@gmail.com
- Protect not only user-writes but also user-reads.


Thanks,
SJ

> 
> SeongJae Park (2):
>   mm/damon/sysfs-schemes: protect memcg_path kfree() with
>     damon_sysfs_lock
>   mm/damon/sysfs-schemes: protect path kfree() with damon_sysfs_lock
> 
>  mm/damon/sysfs-schemes.c | 24 ++++++++++++++++++++++--
>  1 file changed, 22 insertions(+), 2 deletions(-)
> 
> 
> base-commit: 0d45806f3a75bf53e59475b0e56be324f650ab09
> -- 
> 2.47.3

Sent using hkml (https://github.com/sjp38/hackermail)

Re: [RFC PATCH 1/2] mm/damon/sysfs-schemes: protect memcg_path kfree() with damon_sysfs_lock

[sashiko-bot]

Sashiko AI review found 1 potential issue(s):
- [High] Breaking from `mem_cgroup_iter()` without calling `mem_cgroup_iter_break()` leaks a cgroup reference in `damon_sysfs_memcg_path_to_id()`.
--

commit f19bff910905231adad168cfffc97ed67cb1fde3
Author: SeongJae Park <sj@kernel.org>

mm/damon/sysfs-schemes: protect memcg_path kfree() with damon_sysfs_lock

This commit fixes a use-after-free vulnerability by using damon_sysfs_lock
to protect concurrent user-direct reads and writes to the memcg_path sysfs
file. The locking prevents readers from accessing the memory path buffer
while it is being deallocated by a write operation.

> diff --git a/mm/damon/sysfs-schemes.c b/mm/damon/sysfs-schemes.c
> index 5186966dafb35..8d32a20531d49 100644
> --- a/mm/damon/sysfs-schemes.c
> +++ b/mm/damon/sysfs-schemes.c

[ ... ]

> @@ -550,8 +555,13 @@ static ssize_t memcg_path_store(struct kobject *kobj,
>  		return -ENOMEM;
>  
>  	strscpy(path, buf, count + 1);
> +	if (!mutex_trylock(&damon_sysfs_lock)) {
> +		kfree(path);
> +		return -EBUSY;
> +	}
>  	kfree(filter->memcg_path);
>  	filter->memcg_path = path;
> +	mutex_unlock(&damon_sysfs_lock);
>  	return count;
>  }

This isn't a bug introduced by this patch, but I noticed a pre-existing
issue in this file.

Does damon_sysfs_memcg_path_to_id() leak a cgroup reference when breaking
early from the hierarchy walk?

mm/damon/sysfs-schemes.c:damon_sysfs_memcg_path_to_id() {
	...
	for (memcg = mem_cgroup_iter(NULL, NULL, NULL); memcg;
			memcg = mem_cgroup_iter(NULL, memcg, NULL)) {
		/* skip offlined memcg */
		if (!mem_cgroup_online(memcg))
			continue;
		if (damon_sysfs_memcg_path_eq(memcg, path, memcg_path)) {
			*id = mem_cgroup_id(memcg);
			found = true;
			break;
		}
	}
	...
}

According to the API contract, if a hierarchy walk is aborted prematurely
before a round-trip is complete, the caller must use
mem_cgroup_iter_break(NULL, memcg) to drop the reference to the last visited
cgroup.

Because this is missing, could every successful resolution of a memcg path
permanently leak a css reference?

In environments where DAMON configurations are frequently updated (like
dynamically profiling containers), this could lead to a buildup of "zombie"
cgroups that cannot be destroyed, eventually pinning substantial kernel
memory and causing system-wide memory exhaustion.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260422143503.71357-1-sj@kernel.org?part=1

Re: [RFC PATCH 2/2] mm/damon/sysfs-schemes: protect path kfree() with damon_sysfs_lock

[sashiko-bot]

Sashiko AI review found 1 potential issue(s):
- [Low] The commit message incorrectly references the `memcg_path` file instead of the `path` file.
--

commit 9335b00570732d12b29034fc72a20506fd69fbdd
Author: SeongJae Park <sj@kernel.org>

mm/damon/sysfs-schemes: protect path kfree() with damon_sysfs_lock

This commit adds damon_sysfs_lock protection to the path attribute's sysfs show
and store functions. This prevents a use-after-free race condition during
concurrent user-driven reads and writes.

> damon_sysfs_quot_goal->path can be read and written by users, via DAMON
> sysfs memcg_path file.  It can also be indirectly read, for the

This isn't a bug, but the commit message references the memcg_path sysfs file.
Since the patch actually modifies path_show and path_store, which handle the
path attribute for quota goals, should this say "via DAMON sysfs path file"
instead?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260422143503.71357-1-sj@kernel.org?part=2

Re: [RFC PATCH 1/2] mm/damon/sysfs-schemes: protect memcg_path kfree() with damon_sysfs_lock

[SeongJae Park]

On Wed, 22 Apr 2026 20:30:16 +0000 sashiko-bot@kernel.org wrote:

> Sashiko AI review found 1 potential issue(s):
> - [High] Breaking from `mem_cgroup_iter()` without calling `mem_cgroup_iter_break()` leaks a cgroup reference in `damon_sysfs_memcg_path_to_id()`.

Nice finding, but not this patch's fault.  I will separately work on this.

> --
> 
> commit f19bff910905231adad168cfffc97ed67cb1fde3
> Author: SeongJae Park <sj@kernel.org>
> 
> mm/damon/sysfs-schemes: protect memcg_path kfree() with damon_sysfs_lock
> 
> This commit fixes a use-after-free vulnerability by using damon_sysfs_lock
> to protect concurrent user-direct reads and writes to the memcg_path sysfs
> file. The locking prevents readers from accessing the memory path buffer
> while it is being deallocated by a write operation.
> 
> > diff --git a/mm/damon/sysfs-schemes.c b/mm/damon/sysfs-schemes.c
> > index 5186966dafb35..8d32a20531d49 100644
> > --- a/mm/damon/sysfs-schemes.c
> > +++ b/mm/damon/sysfs-schemes.c
> 
> [ ... ]
> 
> > @@ -550,8 +555,13 @@ static ssize_t memcg_path_store(struct kobject *kobj,
> >  		return -ENOMEM;
> >  
> >  	strscpy(path, buf, count + 1);
> > +	if (!mutex_trylock(&damon_sysfs_lock)) {
> > +		kfree(path);
> > +		return -EBUSY;
> > +	}
> >  	kfree(filter->memcg_path);
> >  	filter->memcg_path = path;
> > +	mutex_unlock(&damon_sysfs_lock);
> >  	return count;
> >  }
> 
> This isn't a bug introduced by this patch, but I noticed a pre-existing
> issue in this file.
> 
> Does damon_sysfs_memcg_path_to_id() leak a cgroup reference when breaking
> early from the hierarchy walk?
> 
> mm/damon/sysfs-schemes.c:damon_sysfs_memcg_path_to_id() {
> 	...
> 	for (memcg = mem_cgroup_iter(NULL, NULL, NULL); memcg;
> 			memcg = mem_cgroup_iter(NULL, memcg, NULL)) {
> 		/* skip offlined memcg */
> 		if (!mem_cgroup_online(memcg))
> 			continue;
> 		if (damon_sysfs_memcg_path_eq(memcg, path, memcg_path)) {
> 			*id = mem_cgroup_id(memcg);
> 			found = true;
> 			break;
> 		}
> 	}
> 	...
> }
> 
> According to the API contract, if a hierarchy walk is aborted prematurely
> before a round-trip is complete, the caller must use
> mem_cgroup_iter_break(NULL, memcg) to drop the reference to the last visited
> cgroup.
> 
> Because this is missing, could every successful resolution of a memcg path
> permanently leak a css reference?
> 
> In environments where DAMON configurations are frequently updated (like
> dynamically profiling containers), this could lead to a buildup of "zombie"
> cgroups that cannot be destroyed, eventually pinning substantial kernel
> memory and causing system-wide memory exhaustion.

Nice finding.  As Sashiko also mentions, not this patch's fault, though.  I
will separately work on this.

> 
> -- 
> Sashiko AI review · https://sashiko.dev/#/patchset/20260422143503.71357-1-sj@kernel.org?part=1
> 


Thanks,
SJ

Re: [RFC PATCH 2/2] mm/damon/sysfs-schemes: protect path kfree() with damon_sysfs_lock

[SeongJae Park]

On Wed, 22 Apr 2026 21:02:21 +0000 sashiko-bot@kernel.org wrote:

> Sashiko AI review found 1 potential issue(s):
> - [Low] The commit message incorrectly references the `memcg_path` file instead of the `path` file.
> --
> 
> commit 9335b00570732d12b29034fc72a20506fd69fbdd
> Author: SeongJae Park <sj@kernel.org>
> 
> mm/damon/sysfs-schemes: protect path kfree() with damon_sysfs_lock
> 
> This commit adds damon_sysfs_lock protection to the path attribute's sysfs show
> and store functions. This prevents a use-after-free race condition during
> concurrent user-driven reads and writes.
> 
> > damon_sysfs_quot_goal->path can be read and written by users, via DAMON
> > sysfs memcg_path file.  It can also be indirectly read, for the
> 
> This isn't a bug, but the commit message references the memcg_path sysfs file.
> Since the patch actually modifies path_show and path_store, which handle the
> path attribute for quota goals, should this say "via DAMON sysfs path file"
> instead?

Good finding.  I will fix this in the next revision.

> 
> -- 
> Sashiko AI review · https://sashiko.dev/#/patchset/20260422143503.71357-1-sj@kernel.org?part=2
> 


Thanks,
SJ