CVE-2025-38031

What it actually does

Reference count leak on parallel_data objects in padata reorder_work when queue_work() returns false because the item is already queued, leaving incremented refcounts unreleased and causing memory leaks.

Why it matters to the business

Kernel memory leaks can lead to gradual resource exhaustion, system instability, or crashes on Linux systems performing parallel data operations such as cryptography, increasing operational overhead and unplanned downtime especially in long-running servers.

How an attack unfolds

An attacker triggers repeated padata allocation paths (for example via cryptomgr_probe workloads) under conditions where queue_work() fails due to an already-queued item; the unconditional refcount increment is never decremented, accumulating leaked kernel objects that may be leveraged alongside other kernel flaws for privilege escalation or denial of service.

How to fix it

Upgrade Linux kernel to a fixed version such as 5.10.238 or apply commit b9ad8e50e8589607e68e6c4cefa7f72bf35a2cb1; rebuild and reboot affected systems; for Mageia 5 update libpng12 to 1.2.56-1.mga5 if the package is present.

How to confirm the fix worked

Verify running kernel version is at or above the listed fixed releases, confirm the patch is present in the source tree, and monitor for absence of the unreferenced object backtrace involving padata_alloc_pd and cryptomgr_probe.

Typical attack path

1. Identify or induce workloads that invoke padata_alloc_pd and queue_work in reorder paths
2. Force repeated queue_work failures by racing or flooding the workqueue
3. Accumulate unreleased parallel_data references over time
4. Combine with other kernel primitives to convert memory state into exploitation primitives

How to detect it

Search kernel logs and memory leak detectors for backtraces containing padata_alloc_pd, padata_alloc_shell, cryptomgr_probe, and kthread; monitor for repeated allocation of 192-byte objects without corresponding frees in long-running processes.

• comm "cryptomgr_probe"
• backtrace.*padata_alloc_pd
• Unreferenced object 0x.* size 192
• __kmalloc_cache_noprof.*padata_alloc_pd

What your security team should do

• Prioritize kernel upgrades on all production Linux systems within the next maintenance window
• Enable automated kernel update mechanisms and test the fixed versions in staging
• Review systems for heavy use of padata or crypto manager workloads and increase monitoring cadence
• Track EPSS trend and related Linux kernel privilege-escalation activity for heightened awareness