CVE-2025-38584

Vulnerability

A use-after-free (UAF) race condition exists in the Linux kernel's padata subsystem, specifically in the padata_reorder function. The bug originates from the initial commit of padata and occurs because a reference count on the parallel data (pd) structure is taken at the start of padata_do_parallel and released only at the end of padata_serial_worker. This reference count is required solely for the correct operation of padata_replace. If padata_replace is never invoked, the race does not manifest. However, when padata_replace is called, a window exists where, after a padata item is added to the serial list and releasing the associated spin lock, that padata may be processed and the reference count on pd could be decremented prematurely, leading to a UAF condition [1].

Exploitation

Exploitation requires the ability to trigger padata_replace while parallel work is being processed. An attacker with local access and the ability to influence padata usage (e.g., through certain cryptographic operations or other kernel subsystems that rely on padata) could potentially exploit this race. The attack surface is limited to systems where padata is actively used and where padata_replace can be invoked concurrently with ongoing parallel operations. No authentication is no direct evidence of remote exploitation, but local privilege escalation is plausible if the UAF is successfully leveraged.

Impact

Successful exploitation could allow an attacker to corrupt kernel memory, potentially leading to a denial of service (system crash) or local privilege escalation. The UAF could be used to overwrite freed memory structures, gain arbitrary code execution in kernel context, and thereby elevate privileges from a local unprivileged user to root or escape container boundaries.

Mitigation

The fix, introduced in Linux kernel stable commits, restructures padata_reorder to obtain the next padata before releasing the serial lock, eliminating the race window. Users should apply the latest stable kernel updates containing commits such as f231d5e... [4] or equivalent backports. No workaround is available; updating the kernel is the only mitigation.