[RFC PATCH 0/2] mm/damon/{reclaim,lru_sort}: handle ctx allocation failures

[RFC PATCH 0/2] mm/damon/{reclaim,lru_sort}: handle ctx allocation failures

[SeongJae Park]

DAMON_RECLAIM and DAMON_LRU_SORT could dereference NULL pointers if
their damon_ctx object allocations fail.  The bug is expected to happen
not frequently,, because the allocation is arguably too small to fail on
common setup.  But theoretically it is possible and the consequence is
bad.  Fix those.

The issue was discovered [1] by Sashiko.

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

SeongJae Park (2):
  mm/damon/reclaim: handle ctx allocation failure
  mm/damonn/lru_sort: handle ctx allocation failure

 mm/damon/lru_sort.c | 4 ++++
 mm/damon/reclaim.c  | 4 ++++
 2 files changed, 8 insertions(+)


base-commit: 3c18aac8c775b020a2c50e91051f106dc621ad3e
-- 
2.47.3

[RFC PATCH 1/2] mm/damon/reclaim: handle ctx allocation failure

[SeongJae Park]

DAMON_RECLAIM allocates the damon_ctx object for its kdamond in its init
function.  damon_reclaim_enabled_store() wrongly assumes the allocation
will always succeed once tried.  If the damon_ctx allocation was failed,
therefore, code execution reaches to damon_commit_ctx() while 'ctx' is
NULL.  As a result, it dereferences the NULL 'ctx' pointer.  Avoid the
NULL dereference by returning -ENOMEM if 'ctx' is NULL.

Fixes: 3f7a914ab9a5 ("mm/damon/reclaim: use damon_initialized()")
Cc: <stable@vger.kernel.org> # 6.18.x
Signed-off-by: SeongJae Park <sj@kernel.org>
---
 mm/damon/reclaim.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/mm/damon/reclaim.c b/mm/damon/reclaim.c
index ed446d00ef1cf..ce4499cf4b8b0 100644
--- a/mm/damon/reclaim.c
+++ b/mm/damon/reclaim.c
@@ -399,6 +399,10 @@ static int damon_reclaim_enabled_store(const char *val,
 	if (!damon_initialized())
 		return 0;
 
+	/* damon_modules_new_paddr_ctx_target() in the init function failed. */
+	if (!ctx)
+		return -ENOMEM;
+
 	return damon_reclaim_turn(enabled);
 }
 
-- 
2.47.3

Re: [RFC PATCH 1/2] mm/damon/reclaim: handle ctx allocation failure

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] The patch prevents loading the damon_reclaim module with the 'enabled=Y' parameter by returning -ENOMEM during parameter parsing.
--

commit d55c0d692febe0a6f116ac49f1c1187ff2f47d7b
Author: SeongJae Park <sj@kernel.org>
mm/damon/reclaim: handle ctx allocation failure

This commit adds a check in damon_reclaim_enabled_store() to return -ENOMEM
if the ctx pointer is NULL. This is intended to prevent a NULL pointer
dereference if the context allocation failed during initialization.

Cc: stable@vger.kernel.org # 6.18.x

> diff --git a/mm/damon/reclaim.c b/mm/damon/reclaim.c
> index ed446d00ef1cf..ce4499cf4b8b0 100644
> --- a/mm/damon/reclaim.c
> +++ b/mm/damon/reclaim.c
> @@ -399,6 +399,10 @@ static int damon_reclaim_enabled_store(const char *val,
>  	if (!damon_initialized())
>  		return 0;
>  
> +	/* damon_modules_new_paddr_ctx_target() in the init function failed. */
> +	if (!ctx)
> +		return -ENOMEM;
> +

[Severity: High]
When the damon_reclaim module is loaded with the enabled=Y parameter,
load_module() calls parse_args() before running the module's
damon_reclaim_init() function. At this point, damon_initialized()
returns true since the damon core is already initialized, but ctx is
still NULL.

Will this new check return -ENOMEM and abort the entire module loading
process during parameter parsing instead of successfully loading?

>  	return damon_reclaim_turn(enabled);
>  }

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

Re: [RFC PATCH 1/2] mm/damon/reclaim: handle ctx allocation failure

[SeongJae Park]

On Thu, 28 May 2026 06:50:53 +0000 sashiko-bot@kernel.org wrote:

> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> - [High] The patch prevents loading the damon_reclaim module with the 'enabled=Y' parameter by returning -ENOMEM during parameter parsing.
> --
> 
> commit d55c0d692febe0a6f116ac49f1c1187ff2f47d7b
> Author: SeongJae Park <sj@kernel.org>
> mm/damon/reclaim: handle ctx allocation failure
> 
> This commit adds a check in damon_reclaim_enabled_store() to return -ENOMEM
> if the ctx pointer is NULL. This is intended to prevent a NULL pointer
> dereference if the context allocation failed during initialization.
> 
> Cc: stable@vger.kernel.org # 6.18.x
> 
> > diff --git a/mm/damon/reclaim.c b/mm/damon/reclaim.c
> > index ed446d00ef1cf..ce4499cf4b8b0 100644
> > --- a/mm/damon/reclaim.c
> > +++ b/mm/damon/reclaim.c
> > @@ -399,6 +399,10 @@ static int damon_reclaim_enabled_store(const char *val,
> >  	if (!damon_initialized())
> >  		return 0;
> >  
> > +	/* damon_modules_new_paddr_ctx_target() in the init function failed. */
> > +	if (!ctx)
> > +		return -ENOMEM;
> > +
> 
> [Severity: High]
> When the damon_reclaim module is loaded with the enabled=Y parameter,
> load_module() calls parse_args() before running the module's
> damon_reclaim_init() function. At this point, damon_initialized()
> returns true since the damon core is already initialized, but ctx is
> still NULL.
> 
> Will this new check return -ENOMEM and abort the entire module loading
> process during parameter parsing instead of successfully loading?

DAMON_RECLAIM is not a loadable but static module.  So this cannot happen.


Thanks,
SJ

[...]

[RFC PATCH 2/2] mm/damonn/lru_sort: handle ctx allocation failure

[SeongJae Park]

DAMON_LRU_SORT allocates the damon_ctx object for its kdamond in its
init function.  damon_lru_sort_enabled_store() wrongly assumes the
allocation will always succeed once tried.  If the damon_ctx allocation
was failed, therefore, code execution reaches to damon_commit_ctx()
while 'ctx' is NULL.  As a result, it dereferences the NULL 'ctx'
pointer.  Avoid the NULL dereference  by returning -ENOMEM if 'ctx' is
NULL.

Fixes: c4a8e662c839 ("mm/damon/lru_sort: use damon_initialized()")
Cc: <stable@vger.kernel.org> # 6.18.x
Signed-off-by: SeongJae Park <sj@kernel.org>
---
 mm/damon/lru_sort.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/mm/damon/lru_sort.c b/mm/damon/lru_sort.c
index eca88ed941b32..8298c6001fd09 100644
--- a/mm/damon/lru_sort.c
+++ b/mm/damon/lru_sort.c
@@ -476,6 +476,10 @@ static int damon_lru_sort_enabled_store(const char *val,
 	if (!damon_initialized())
 		return 0;
 
+	/* damon_modules_new_paddr_ctx_target() in the init function failed. */
+	if (!ctx)
+		return -ENOMEM;
+
 	return damon_lru_sort_turn(enabled);
 }
 
-- 
2.47.3

Re: [RFC PATCH 2/2] mm/damonn/lru_sort: handle ctx allocation failure

[sashiko-bot]

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

New issues:
- [High] Module load parameter 'enabled' causes unconditional module load failure.

Pre-existing issues:
- [High] TOCTOU race condition between sysfs store and module initialization leading to data corruption.
--

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

mm/damonn/lru_sort: handle ctx allocation failure

This commit attempts to fix a NULL pointer dereference in
damon_lru_sort_enabled_store() by returning -ENOMEM if the damon_ctx object
failed to allocate during initialization.

> diff --git a/mm/damon/lru_sort.c b/mm/damon/lru_sort.c
> index eca88ed941b32..8298c6001fd09 100644
> --- a/mm/damon/lru_sort.c
> +++ b/mm/damon/lru_sort.c
> @@ -476,6 +476,10 @@ static int damon_lru_sort_enabled_store(const char *val,
>  	if (!damon_initialized())
>  		return 0;
>  
> +	/* damon_modules_new_paddr_ctx_target() in the init function failed. */
> +	if (!ctx)
> +		return -ENOMEM;
> +

[Severity: High]
Will this cause an unconditional module load failure when passing the
enabled parameter at load time?

When loading the module with modprobe damon_lru_sort enabled=Y, the kernel
calls parse_args() before the module's init function damon_lru_sort_init()
is executed.

At this point, damon_initialized() returns true because the damon_core
dependency is already initialized, but ctx is still NULL since the module
init function hasn't run yet.

Could this evaluate to true and return -ENOMEM, causing the entire module
loading process to fail and abort?

>  	return damon_lru_sort_turn(enabled);
>  }

[Severity: High]
This isn't a bug introduced by this patch, but is there a TOCTOU race
condition here between the sysfs store and module initialization?

The kernel exposes module parameter sysfs files via mod_sysfs_setup()
before executing the module's initcall do_init_module().

If a userspace process writes to this sysfs file concurrently while
damon_lru_sort_init() is executing, could it trigger the following sequence?

Userspace sysfs write happens right after damon_lru_sort_init() allocates
ctx. This callback sees ctx != NULL and calls damon_lru_sort_turn(true).

Concurrently, damon_lru_sort_init() continues, reads enabled == true
(updated by the sysfs store), and also calls damon_lru_sort_turn(true).

Does this concurrent execution of damon_lru_sort_apply_parameters() and
damon_commit_ctx() on the same ctx without locks lead to list corruption
or double frees?

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

Re: [RFC PATCH 2/2] mm/damonn/lru_sort: handle ctx allocation failure

[SeongJae Park]

On Thu, 28 May 2026 07:29:55 +0000 sashiko-bot@kernel.org wrote:

> Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
> 
> New issues:
> - [High] Module load parameter 'enabled' causes unconditional module load failure.
> 
> Pre-existing issues:
> - [High] TOCTOU race condition between sysfs store and module initialization leading to data corruption.
> --
> 
> commit 98350211104d3088f79c58844d29a85c013ac178
> Author: SeongJae Park <sj@kernel.org>
> 
> mm/damonn/lru_sort: handle ctx allocation failure
> 
> This commit attempts to fix a NULL pointer dereference in
> damon_lru_sort_enabled_store() by returning -ENOMEM if the damon_ctx object
> failed to allocate during initialization.
> 
> > diff --git a/mm/damon/lru_sort.c b/mm/damon/lru_sort.c
> > index eca88ed941b32..8298c6001fd09 100644
> > --- a/mm/damon/lru_sort.c
> > +++ b/mm/damon/lru_sort.c
> > @@ -476,6 +476,10 @@ static int damon_lru_sort_enabled_store(const char *val,
> >  	if (!damon_initialized())
> >  		return 0;
> >  
> > +	/* damon_modules_new_paddr_ctx_target() in the init function failed. */
> > +	if (!ctx)
> > +		return -ENOMEM;
> > +
> 
> [Severity: High]
> Will this cause an unconditional module load failure when passing the
> enabled parameter at load time?
> 
> When loading the module with modprobe damon_lru_sort enabled=Y, the kernel
> calls parse_args() before the module's init function damon_lru_sort_init()
> is executed.
> 
> At this point, damon_initialized() returns true because the damon_core
> dependency is already initialized, but ctx is still NULL since the module
> init function hasn't run yet.
> 
> Could this evaluate to true and return -ENOMEM, causing the entire module
> loading process to fail and abort?

DAMON_LRU_SORT is not a loadable but static module.  So this cannot happen.

> 
> >  	return damon_lru_sort_turn(enabled);
> >  }
> 
> [Severity: High]
> This isn't a bug introduced by this patch, but is there a TOCTOU race
> condition here between the sysfs store and module initialization?
> 
> The kernel exposes module parameter sysfs files via mod_sysfs_setup()
> before executing the module's initcall do_init_module().
> 
> If a userspace process writes to this sysfs file concurrently while
> damon_lru_sort_init() is executing, could it trigger the following sequence?
> 
> Userspace sysfs write happens right after damon_lru_sort_init() allocates
> ctx. This callback sees ctx != NULL and calls damon_lru_sort_turn(true).
> 
> Concurrently, damon_lru_sort_init() continues, reads enabled == true
> (updated by the sysfs store), and also calls damon_lru_sort_turn(true).
> 
> Does this concurrent execution of damon_lru_sort_apply_parameters() and
> damon_commit_ctx() on the same ctx without locks lead to list corruption
> or double frees?

Again, DAMON_LRU_SORT is not loadable.  So, no.


Thanks,
SJ

[...]