padata: Fix pd UAF once and for all

[ Upstream commit 71203f68c7749609d7fc8ae6ad054bdedeb24f91 ]

There is a race condition/UAF in padata_reorder that goes back
to the initial commit.  A reference count is taken at the start
of the process in padata_do_parallel, and released at the end in
padata_serial_worker.

This reference count is (and only is) required for padata_replace
to function correctly.  If padata_replace is never called then
there is no issue.

In the function padata_reorder which serves as the core of padata,
as soon as padata is added to queue->serial.list, and the associated
spin lock released, that padata may be processed and the reference
count on pd would go away.

Fix this by getting the next padata before the squeue->serial lock
is released.

In order to make this possible, simplify padata_reorder by only
calling it once the next padata arrives.

BUG=b/440034137
TEST=presubmit
RELEASE_NOTE=Fixed CVE-2025-38584 in the Linux kernel.

cos-patch: security-moderate
Fixes: 16295bec6398 ("padata: Generic parallelization/serialization interface")
Change-Id: I4083200549ddd489346f5ba724411763aab2a660
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
[ Adjust context of padata_find_next(). Replace
cpumask_next_wrap(cpu, pd->cpumask.pcpu) with
cpumask_next_wrap(cpu, pd->cpumask.pcpu, -1, false) in padata_reorder() in
v6.12 according to dc5bb9b769c9 ("cpumask: deprecate cpumask_next_wrap()") and
f954a2d37637 ("padata: switch padata_find_next() to using cpumask_next_wrap()")
. ]
Signed-off-by: Bin Lan <lanbincn@139.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Signed-off-by: Kernel CVE Triage Automation <cloud-image-kernel-cve-triage-automation@prod.google.com>
Reviewed-on: https://cos-review.googlesource.com/c/third_party/kernel/+/152303
Reviewed-by: Miri Amarilio <mirilio@google.com>
Reviewed-by: Daniel Velasquez <rdvelasquez@google.com>
Tested-by: Cusky Presubmit Bot <presubmit@cos-infra-prod.iam.gserviceaccount.com>