* [RFC PATCH] mm/damon/sysfs-schemes: hold damon_sysfs_lock in target_value_store()
@ 2026-10-20 14:47 SJ Park
0 siblings, 0 replies; only message in thread
From: SJ Park @ 2026-10-20 14:47 UTC (permalink / raw)
Cc: SJ Park, stable, Andrew Morton, damon, linux-kernel, linux-mm
Remove a race condition under certain use cases that can trigger
divide-by-zero.
damon_sysfs_add_quota_score() setup damos quota goal as user configured
and pass to the core layer. Because it could have a race with
damos_sysfs_quota_goals_rm_dirs(), which destructs the files that carry
user configuration, both are called under damon_sysfs_lock protection.
The damos quota goal setup disallows zero target_value parameter because
it can be used as a denominator later in the core layer function,
damos_quota_score(). Otherwise, divide-by-zero can happen.
For the zero value check and final assignment,
damon_sysfs_add_quota_score() reads damos_sysfs_quota_goal->target_value
twice. And user can update damos_sysfs_quota_goal->target_value via
target_value_store(), which doesn't hold damon_sysfs_lock. As a result,
a time-of-check-to time-of-use (toctou) race can happen. If the user
sets the value to zero between the zero value check and final
target_value assignment, zero target_value is passed to the core layer
and results in divide-by-zero.
Fix by holding damon_sysfs_lock in target_value_store() while saving the
value. The read side, damon_sysfs_add_quota_score(), is already called
while holding the same mutex lock, so it avoids the race.
Users could reproduce the race by writing zero to the target_value sysfs
file while DAMON is starting, or online parameters update is ongoing.
The issue will only rarely happen in the real use cases. It requires
sysfs write permission. The race window is short. Sane users wouldn't
write zero target_value. Especially, they wouldn't do that while DAMON
enablement and/or online parameters update is ongoing. That said, the
probability is not zero, and the consequence (divide-by-zero) is quite
bad.
Closes: https://sashiko.dev/#/bug/linux-7f814c9a-986f-4103-a55a-ef9537dcf62b
Fixes: 8b549a4fd3c5 ("mm/damon/sysfs-schemes: commit damos quota goals user input to DAMOS")
Cc: <stable@vger.kernel.org> # 6.8.x
Signed-off-by: SJ Park <sj@kernel.org>
---
mm/damon/sysfs-schemes.c | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/mm/damon/sysfs-schemes.c b/mm/damon/sysfs-schemes.c
index 8f083611741fd..55298a17b653a 100644
--- a/mm/damon/sysfs-schemes.c
+++ b/mm/damon/sysfs-schemes.c
@@ -1355,7 +1355,13 @@ static ssize_t target_value_store(struct kobject *kobj,
{
struct damos_sysfs_quota_goal *goal = container_of(kobj, struct
damos_sysfs_quota_goal, kobj);
- int err = kstrtoul(buf, 0, &goal->target_value);
+ unsigned long target_value;
+ int err = kstrtoul(buf, 0, &target_value);
+
+ if (!mutex_trylock(&damon_sysfs_lock))
+ return -EBUSY;
+ goal->target_value = target_value;
+ mutex_unlock(&damon_sysfs_lock);
return err ? err : count;
}
base-commit: 33560dfbb2df9b2d1525fd51ceeca3c1167431e3
--
2.47.3
^ permalink raw reply [flat|nested] only message in thread
only message in thread, other threads:[~2026-10-20 14:47 UTC | newest]
Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2026-10-20 14:47 [RFC PATCH] mm/damon/sysfs-schemes: hold damon_sysfs_lock in target_value_store() SJ Park
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®