mm/damon/{reclaim,lru_sort}: handle ctx allocation failures

RFC PATCH In review SeongJae Park 2 participants 7 messages May 28

Subsystems (3)

Stable branch Memory management DAMON

lore

Share & tools

lore

SeongJae Park

author maintainer

2026-05-28 06:11 UTC #0 lore raw

cover mm/damon/{reclaim,lru_sort}: handle ctx allocation failures

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/[email protected]

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

Signature · 1 line

2.47.3

SeongJae Park

author maintainer

2026-05-28 06:11 UTC #1 lore raw

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

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 <[email protected]> # 6.18.x

Signed-off-by SeongJae Park <[email protected]>

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

mm/damon/reclaim.c +4 -0

index ed446d00ef1cf..ce4499cf4b8b0 100644
@@ -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);
 }

Signature · 1 line

2.47.3

[email protected]

AI review

2026-05-28 06:50 UTC #2 lore raw

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

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…

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 <[email protected]>
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 [email protected] # 6.18.x

mm/damon/reclaim.c static int damon_reclaim_enabled_store(const char *val, · line 405

Quoted 12 lines

mm/damon/reclaim.c +4 -0

index ed446d00ef1cf..ce4499cf4b8b0 100644
@@ -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?

Quoted 2 lines

mm/damon/reclaim.c +0 -0

 	return damon_reclaim_turn(enabled);
 }

Signature · 1 line

Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=1

SeongJae Park

author maintainer

2026-05-28 14:00 UTC #3 lore raw

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

Quoted 34 lines · On Thu, 28 May 2026 06:50:53 +0000 [email protected] 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 <[email protected]>
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 [email protected] # 6.18.x
mm/damon/reclaim.c static int damon_reclaim_enabled_store(const char *val, · line 405
Quoted 12 lines
mm/damon/reclaim.c +4 -0
index ed446d00ef1cf..ce4499cf4b8b0 100644
@@ -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.

Quoted 2 lines

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

[...]

SeongJae Park

author maintainer

2026-05-28 06:11 UTC #4 lore raw

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

In reply to 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 <[email protected]> # 6.18.x

Signed-off-by SeongJae Park <[email protected]>

---
 mm/damon/lru_sort.c | 4 ++++
 1 file changed, 4 insertions(+)

mm/damon/lru_sort.c +4 -0

index eca88ed941b32..8298c6001fd09 100644
@@ -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);
 }

Signature · 1 line

2.47.3

[email protected]

AI review

2026-05-28 07:29 UTC #5 lore raw

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

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 <[email protected]>

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.

mm/damon/lru_sort.c static int damon_lru_sort_enabled_store(const char *val, · line 482

Quoted 12 lines

mm/damon/lru_sort.c +4 -0

index eca88ed941b32..8298c6001fd09 100644
@@ -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?

mm/damon/lru_sort.c static int damon_lru_sort_enabled_store(const char *val, · line 484

Quoted 2 lines

mm/damon/lru_sort.c +0 -0

 	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?

Signature · 1 line

Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=2

SeongJae Park

author maintainer

2026-05-28 14:03 UTC #6 lore raw

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

Quoted 39 lines · On Thu, 28 May 2026 07:29:55 +0000 [email protected] 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 <[email protected]>
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.
mm/damon/lru_sort.c static int damon_lru_sort_enabled_store(const char *val, · line 482
Quoted 12 lines
mm/damon/lru_sort.c +4 -0
index eca88ed941b32..8298c6001fd09 100644
@@ -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.

Quoted 6 lines

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.

Quoted 17 lines

mm/damon/lru_sort.c static int damon_lru_sort_enabled_store(const char *val, · line 484
Quoted 3 lines
mm/damon/lru_sort.c +0 -0
 	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).

Quoted 6 lines

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

[...]