CVE-2025-21693: mm: zswap: properly synchronize freeing resources during CPU hotunplug

In the Linux kernel, the following vulnerability has been resolved:

mm: zswap: properly synchronize freeing resources during CPU hotunplug

In zswapcompress() and zswapdecompress(), the per-CPU acompctx of the current CPU at the beginning of the operation is retrieved and used throughout. However, since neither preemption nor migration are disabled, it is possible that the operation continues on a different CPU.

If the original CPU is hotunplugged while the acompctx is still in use, we run into a UAF bug as some of the resources attached to the acompctx are freed during hotunplug in zswapcpucompdead() (i.e. acompctx.buffer, acompctx.req, or acompctx.acomp).

The problem was introduced in commit 1ec3b5fe6eec ("mm/zswap: move to use cryptoacomp API for hardware acceleration") when the switch to the cryptoacomp API was made. Prior to that, the per-CPU cryptocomp was retrieved using getcpuptr() which disables preemption and makes sure the CPU cannot go away from under us. Preemption cannot be disabled with the cryptoacomp API as a sleepable context is needed.

Use the acompctx.mutex to synchronize CPU hotplug callbacks allocating and freeing resources with compression/decompression paths. Make sure that acompctx.req is NULL when the resources are freed. In the compression/decompression paths, check if acompctx.req is NULL after acquiring the mutex (meaning the CPU was offlined) and retry on the new CPU.

The initialization of acompctx.mutex is moved from the CPU hotplug callback to the pool initialization where it belongs (where the mutex is allocated). In addition to adding clarity, this makes sure that CPU hotplug cannot reinitialize a mutex that is already locked by compression/decompression.

Previously a fix was attempted by holding cpusreadlock() [1]. This would have caused a potential deadlock as it is possible for code already holding the lock to fall into reclaim and enter zswap (causing a deadlock). A fix was also attempted using SRCU for synchronization, but Johannes pointed out that synchronizesrcu() cannot be used in CPU hotplug notifiers [2].

Alternative fixes that were considered/attempted and could have worked: - Refcounting the per-CPU acompctx. This involves complexity in handling the race between the refcount dropping to zero in zswap[de]compress() and the refcount being re-initialized when the CPU is onlined. - Disabling migration before getting the per-CPU acompctx [3], but that's discouraged and is a much bigger hammer than needed, and could result in subtle performance issues.

[1]