* [PATCH 7.3.y] mm/damon/sysfs-schemes: read sysfs_filter->sz_range only once [not found] <20261107050434-failed-7.3-af19aff38d6f@kernel.org> @ 2026-11-09 0:57 ` SJ Park 2026-11-09 1:11 ` sashiko-bot 2026-11-09 15:53 ` Sasha Levin 0 siblings, 2 replies; 3+ messages in thread From: SJ Park @ 2026-11-09 0:57 UTC (permalink / raw) To: stable Cc: damon, SJ Park, Andrew Morton, Brendan Higgins, David Gow, Usama Arif DAMON sysfs interface reads the user-provided size range arguments for hugepage_size type DAMOS filter twice. Once for validation, and once again for assignments to the variable that will be passed to the core layer. If the user updates the arguments in parallel, an invalid size range could be passed to the core layer. Avoid it by doing the assignments first, and then validating the assigned variables before passing those to the core layer. User impact of the bug should be trivial. From the core layer's perspective, the invalid size range is not really invalid. It just works as having a weird size range. No critical issues such as a crash or a leak could happen. And sane users ain't do such parallel arguments update anyway. If they do, such racy behavior is arguably somewhat expected and deserved. That said, there is no reason to keep such races. Link: https://lore.kernel.org/20260914142327.92510-3-sj@kernel.org Fixes: ea1f204ba29a ("mm/damon/sysfs-schemes: add files for setting damos_filter->sz_range") Signed-off-by: SJ Park <sj@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Cc: Brendan Higgins <brendan.higgins@linux.dev> Cc: David Gow <davidgow@davidgow.net> Cc: Usama Arif <usamaarif642@gmail.com> Cc: <stable@vger.kernel.org> (cherry picked from commit af19aff38d6faea35b10f26cca32d0e54f8aea5e) Signed-off-by: SJ Park <sj@kernel.org> --- mm/damon/sysfs-schemes.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/mm/damon/sysfs-schemes.c b/mm/damon/sysfs-schemes.c index 32f495a96b17a..c3a5b12648498 100644 --- a/mm/damon/sysfs-schemes.c +++ b/mm/damon/sysfs-schemes.c @@ -2831,12 +2831,11 @@ static int damon_sysfs_add_scheme_filters(struct damos *scheme, } else if (filter->type == DAMOS_FILTER_TYPE_TARGET) { filter->target_idx = sysfs_filter->target_idx; } else if (filter->type == DAMOS_FILTER_TYPE_HUGEPAGE_SIZE) { - if (sysfs_filter->sz_range.min > - sysfs_filter->sz_range.max) { + filter->sz_range = sysfs_filter->sz_range; + if (filter->sz_range.min > filter->sz_range.max) { damos_destroy_filter(filter); return -EINVAL; } - filter->sz_range = sysfs_filter->sz_range; } damos_add_filter(scheme, filter); -- 2.47.3 ^ permalink raw reply related [flat|nested] 3+ messages in thread
* Re: [PATCH 7.3.y] mm/damon/sysfs-schemes: read sysfs_filter->sz_range only once 2026-11-09 0:57 ` [PATCH 7.3.y] mm/damon/sysfs-schemes: read sysfs_filter->sz_range only once SJ Park @ 2026-11-09 1:11 ` sashiko-bot 2026-11-09 15:53 ` Sasha Levin 1 sibling, 0 replies; 3+ messages in thread From: sashiko-bot @ 2026-11-09 1:11 UTC (permalink / raw) To: SJ Park; +Cc: damon > DAMON sysfs interface reads the user-provided size range arguments for > hugepage_size type DAMOS filter twice. Once for validation, and once > again for assignments to the variable that will be passed to the core > layer. If the user updates the arguments in parallel, an invalid size > range could be passed to the core layer. Avoid it by doing the > assignments first, and then validating the assigned variables before > passing those to the core layer. > > User impact of the bug should be trivial. From the core layer's > perspective, the invalid size range is not really invalid. It just works > as having a weird size range. No critical issues such as a crash or a > leak could happen. And sane users ain't do such parallel arguments update > anyway. If they do, such racy behavior is arguably somewhat expected and > deserved. That said, there is no reason to keep such races. > > Link: https://lore.kernel.org/20260914142327.92510-3-sj@kernel.org > Fixes: ea1f204ba29a ("mm/damon/sysfs-schemes: add files for setting damos_filter->sz_range") > Signed-off-by: SJ Park <sj@kernel.org> > Signed-off-by: Andrew Morton <akpm@linux-foundation.org> > Cc: Brendan Higgins <brendan.higgins@linux.dev> > Cc: David Gow <davidgow@davidgow.net> > Cc: Usama Arif <usamaarif642@gmail.com> > Cc: <stable@vger.kernel.org> > (cherry picked from commit af19aff38d6faea35b10f26cca32d0e54f8aea5e) > Signed-off-by: SJ Park <sj@kernel.org> Sashiko has reviewed this patch and found no issues. -- Sashiko AI review · https://sashiko.dev/#/patchset/20261109005724.87550-1-sj@kernel.org?part=1 ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [PATCH 7.3.y] mm/damon/sysfs-schemes: read sysfs_filter->sz_range only once 2026-11-09 0:57 ` [PATCH 7.3.y] mm/damon/sysfs-schemes: read sysfs_filter->sz_range only once SJ Park 2026-11-09 1:11 ` sashiko-bot @ 2026-11-09 15:53 ` Sasha Levin 1 sibling, 0 replies; 3+ messages in thread From: Sasha Levin @ 2026-11-09 15:53 UTC (permalink / raw) To: stable Cc: Sasha Levin, damon, SJ Park, Andrew Morton, Brendan Higgins, David Gow, Usama Arif > mm/damon/sysfs-schemes: read sysfs_filter->sz_range only once Queued for 7.3, thanks. -- Thanks, Sasha ^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2026-11-09 15:54 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <20261107050434-failed-7.3-af19aff38d6f@kernel.org>
2026-11-09 0:57 ` [PATCH 7.3.y] mm/damon/sysfs-schemes: read sysfs_filter->sz_range only once SJ Park
2026-11-09 1:11 ` sashiko-bot
2026-11-09 15:53 ` Sasha Levin
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox