Re: [PATCH 13/23] sched/core: Use RCU to protect access of HK_TYPE_KERNEL_NOISE cpumask

[sashiko-bot@kernel.org]

Sashiko AI review found 1 potential issue(s):
- [High] The commit message incorrectly claims that `housekeeping_cpumask()` will warn if used in an invalid context, masking potential RCU safety violations elsewhere in the kernel. Specifically, `housekeeping_dereference_check(type)` returns `true` for `HK_TYPE_KERNEL_NOISE`, causing `rcu_dereference_all_check()` to bypass the `rcu_read_lock_held()` validation. This false assumption of a safety net led the author to miss unprotected accesses, such as the `housekeeping_show` sysfs handler in `drivers/base/cpu.c` which does not hold `rcu_read_lock()`. Because `housekeeping_update()` replaces and frees the old mask via `kfree()` after `synchronize_rcu()`, concurrent execution of `housekeeping_show()` results in a Use-After-Free. While the lockdep omission is patched later in the series by commit "sched/isolation: Extend housekeeping_dereference_check() to cover changes in nohz_full or manged_irqs cpumasks", the underlying Use-After-Free vulnerability in `drivers/base/cpu.c` remains unfixed throughout the entire series.
--

commit 7a774b36f9d9b430bf7171534b53f6145556f483
Author: Waiman Long <longman@redhat.com>

sched/core: Use RCU to protect access of HK_TYPE_KERNEL_NOISE cpumask

This commit adds RCU protection to the HK_TYPE_KERNEL_NOISE cpumask in
get_nohz_timer_target(), as the mask can now be changed at runtime. It
also notes that housekeeping_cpumask() will warn if used in an invalid
context.

> As HK_TYPE_KERNEL_NOISE is going to be changeable at run time, use
> RCU to protect access to the cpumask when needed. Some access of the
> HK_TYPE_KERNEL_NOISE cpumask is done inside the tick code that has
> interrupt disabled which is a rcu_read_lock() critical section. Anyway,
> housekeeping_cpumask() will warn if they are used in invalid context.

Is this description accurate? Looking at housekeeping_dereference_check(),
it returns true for HK_TYPE_KERNEL_NOISE, which causes
rcu_dereference_all_check() to bypass the rcu_read_lock_held() validation.
This means lockdep will not warn about missing RCU read locks for this
specific mask.

Because the mask can now be replaced and freed dynamically after
synchronize_rcu(), does this introduce a use-after-free in other readers
that don't hold the RCU read lock?

For example, housekeeping_show() in drivers/base/cpu.c reads this mask to
print it to sysfs:

drivers/base/cpu.c:housekeeping_show() {
    ...
    return sysfs_emit(buf, "%*pbl\n",
                      cpumask_pr_args(housekeeping_cpumask(type)));
}

Since housekeeping_show() doesn't hold rcu_read_lock(), could a concurrent
update of the cpumask cause cpumask_pr_args() to access freed memory?

While the lockdep omission is patched later in this series by the commit
"sched/isolation: Extend housekeeping_dereference_check() to cover changes
in nohz_full or manged_irqs cpumasks", the underlying use-after-free
regression in drivers/base/cpu.c appears to remain unfixed throughout the
series.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260421030351.281436-1-longman@redhat.com?part=13