CVE-2025-38584

What it actually does

Race condition in padata_reorder releases the pd reference count prematurely once the item is queued to squeue->serial.list, enabling a use-after-free of the pd structure when padata_serial_worker later processes it.

Why it matters to the business

Local attackers on affected Linux systems can trigger kernel crashes or arbitrary code execution, resulting in full host compromise, service outages, and potential lateral movement in container or multi-tenant environments.

How an attack unfolds

An attacker invokes padata_do_parallel to queue work, then races padata_reorder by releasing the serial lock immediately after enqueue; if padata_replace or serial_worker runs concurrently the freed pd is dereferenced, allowing memory corruption and privilege escalation.

How to fix it

Upgrade the Linux kernel to commit dbe3e911a59bda6de96e7cae387ff882c2c177fa or later. For listed Chainguard packages, update to version 0.53.0-r0 or newer.

How to confirm the fix worked

Confirm the running kernel contains commit dbe3e911a59bda6de96e7cae387ff882c2c177fa; inspect padata.c to verify the reorder change that acquires the next padata before releasing the serial lock.

Typical attack path

1. Obtain local code execution as an unprivileged user
2. Invoke padata parallel/serial paths to enqueue work
3. Time operations to trigger the window between enqueue and reference release
4. Exploit the resulting UAF for kernel memory corruption
5. Escalate to root or container escape

How to detect it

Review kernel logs for oops/panic messages referencing padata_reorder or pd use-after-free; correlate with processes performing parallel data operations around crash times.

What your security team should do

• Apply the kernel fix immediately on all production systems
• Restrict untrusted local code execution until patched
• Reboot after package upgrades to load the corrected kernel
• Audit container hosts for similar padata-related stability issues