FlawAtlas
Search the atlas
CVE-2025-38584 Not scored

padata: Fix pd UAF once and for all

In the Linux kernel, the following vulnerability has been resolved: padata: Fix pd UAF once and for all 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.

Exploit probability 0.2%
Published August 19, 2025
Required by Not available
Last source change July 15, 2026

02 / AFFECTED SOFTWARE

Affected packages

Linux Kernel
Unknown Unknown

03 / CONNECTIONS

Connected vulnerabilities

related CGA-47W2-62QP-842H
related OPENSUSE-SU-2025:20081-1
related SUSE-SU-2025:03600-1
related SUSE-SU-2025:03601-1
related SUSE-SU-2025:03633-1
related SUSE-SU-2025:03634-1
related SUSE-SU-2025:20851-1
related SUSE-SU-2025:20861-1
related SUSE-SU-2025:20870-1
related SUSE-SU-2025:20898-1
related SUSE-SU-2025:21074-1
related SUSE-SU-2025:21139-1
related SUSE-SU-2025:21179-1
related SUSE-SU-2025:3725-1
related SUSE-SU-2025:3751-1

04 / EVIDENCE

Source records

Open Source Vulnerabilities CVE-2025-38584

In the Linux kernel, the following vulnerability has been resolved: padata: Fix pd UAF once and for all 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.

View original source

05 / REFERENCES

Further evidence