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. Fixes: ea1f204ba29a ("mm/damon/sysfs-schemes: add files for setting damos_filter->sz_range") Cc: # 6.15.x Signed-off-by: SJ Park --- mm/damon/sysfs-schemes.c | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/mm/damon/sysfs-schemes.c b/mm/damon/sysfs-schemes.c index 3c1c1cb387fec..8c8ab82c8facc 100644 --- a/mm/damon/sysfs-schemes.c +++ b/mm/damon/sysfs-schemes.c @@ -2840,13 +2840,12 @@ 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->range_min > - sysfs_filter->range_max) { + filter->sz_range.min = sysfs_filter->range_min; + filter->sz_range.max = sysfs_filter->range_max; + if (filter->range_min > filter->range_max) { damos_destroy_filter(filter); return -EINVAL; } - filter->sz_range.min = sysfs_filter->range_min; - filter->sz_range.max = sysfs_filter->range_max; } else if (filter->type == DAMOS_FILTER_TYPE_PROBE_HITS_WSUM) { filter->range_min = sysfs_filter->range_min; filter->range_max = sysfs_filter->range_max; -- 2.47.3