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

On 4/21/26 11:09 PM, [email protected] wrote:
> 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 <[email protected]>
>
> 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.

The change to enable proper lock protection checking for 
HK_TYPE_KERNEL_NOISE is made in a later patch after all the RCU guards 
are properly added.

>
> 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.
>
That is missed in the current series. Will fix that in the next version.

Cheers,
Longman