{"dataType":"CVE_RECORD","dataVersion":"5.2","cveMetadata":{"cveId":"CVE-2025-21693","assignerOrgId":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","state":"PUBLISHED","assignerShortName":"Linux","dateReserved":"2024-12-29T08:45:45.742Z","datePublished":"2025-02-10T15:58:49.056Z","dateUpdated":"2026-08-05T11:53:39.821Z"},"containers":{"cna":{"providerMetadata":{"orgId":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","shortName":"Linux","dateUpdated":"2026-08-05T11:53:39.821Z"},"descriptions":[{"lang":"en","value":"In the Linux kernel, the following vulnerability has been resolved:\n\nmm: zswap: properly synchronize freeing resources during CPU hotunplug\n\nIn zswap_compress() and zswap_decompress(), the per-CPU acomp_ctx of the\ncurrent CPU at the beginning of the operation is retrieved and used\nthroughout.  However, since neither preemption nor migration are disabled,\nit is possible that the operation continues on a different CPU.\n\nIf the original CPU is hotunplugged while the acomp_ctx is still in use,\nwe run into a UAF bug as some of the resources attached to the acomp_ctx\nare freed during hotunplug in zswap_cpu_comp_dead() (i.e. \nacomp_ctx.buffer, acomp_ctx.req, or acomp_ctx.acomp).\n\nThe problem was introduced in commit 1ec3b5fe6eec (\"mm/zswap: move to use\ncrypto_acomp API for hardware acceleration\") when the switch to the\ncrypto_acomp API was made.  Prior to that, the per-CPU crypto_comp was\nretrieved using get_cpu_ptr() which disables preemption and makes sure the\nCPU cannot go away from under us.  Preemption cannot be disabled with the\ncrypto_acomp API as a sleepable context is needed.\n\nUse the acomp_ctx.mutex to synchronize CPU hotplug callbacks allocating\nand freeing resources with compression/decompression paths.  Make sure\nthat acomp_ctx.req is NULL when the resources are freed.  In the\ncompression/decompression paths, check if acomp_ctx.req is NULL after\nacquiring the mutex (meaning the CPU was offlined) and retry on the new\nCPU.\n\nThe initialization of acomp_ctx.mutex is moved from the CPU hotplug\ncallback to the pool initialization where it belongs (where the mutex is\nallocated).  In addition to adding clarity, this makes sure that CPU\nhotplug cannot reinitialize a mutex that is already locked by\ncompression/decompression.\n\nPreviously a fix was attempted by holding cpus_read_lock() [1].  This\nwould have caused a potential deadlock as it is possible for code already\nholding the lock to fall into reclaim and enter zswap (causing a\ndeadlock).  A fix was also attempted using SRCU for synchronization, but\nJohannes pointed out that synchronize_srcu() cannot be used in CPU hotplug\nnotifiers [2].\n\nAlternative fixes that were considered/attempted and could have worked:\n- Refcounting the per-CPU acomp_ctx. This involves complexity in\n  handling the race between the refcount dropping to zero in\n  zswap_[de]compress() and the refcount being re-initialized when the\n  CPU is onlined.\n- Disabling migration before getting the per-CPU acomp_ctx [3], but\n  that's discouraged and is a much bigger hammer than needed, and could\n  result in subtle performance issues.\n\n[1]https://lkml.kernel.org/20241219212437.2714151-1-yosryahmed@google.com/\n[2]https://lkml.kernel.org/20250107074724.1756696-2-yosryahmed@google.com/\n[3]https://lkml.kernel.org/20250107222236.2715883-2-yosryahmed@google.com/\n\n[yosryahmed@google.com: remove comment]"}],"metrics":[{"cvssV3_1":{"version":"3.1","vectorString":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H","baseScore":7.8,"baseSeverity":"HIGH"},"scenarios":[{"lang":"en","value":"AV:L - The UAF is reached through local memory-management activity — `madvise(MADV_PAGEOUT)`/reclaim driving `zswap_store()`→`zswap_compress()` and swap-in faults driving `zswap_load()`→`zswap_decompress()` — raced against a local CPU offline transition (sysfs `cpuN/online`, suspend/resume, or hypervisor vCPU hot-remove). No remote peer or network input reaches `mm/zswap.c`.\nAC:L - The attacker fully controls the zswap side (unbounded `MADV_PAGEOUT`/swap-in loops on threads pinned to each CPU via `sched_setaffinity()`), and the offline operation itself performs the migration that opens the window, since `CPUHP_MM_ZSWP_POOL_PREPARE` teardown runs only after the dying CPU's tasks have been pushed to other CPUs; the pre-fix per-CPU mutex additionally parks several attacker threads on the dying CPU's ctx so they all wake onto freed resources. Hotplug or suspend/resume cycles can be repeated indefinitely until the race lands, and zswap is a mainstream distro config (`CONFIG_ZSWAP`, `CONFIG_ZSWAP_DEFAULT_ON`).\nPR:L - The compress/decompress half needs no privilege at all — any user's own anonymous memory plus `madvise()` reaches it with no `capable()` check — and the offline half requires no elevated credentials in realistic deployments: the identical CPU-down sequence runs on every suspend/resume, which an unprivileged desktop/laptop/Android session can request via logind/polkit, and cloud guests (Xen vCPU availability, pseries DLPAR, s390, ACPI eject) and vendor Android hotplug governors offline CPUs autonomously while the attacker keeps zswap traffic in flight.\nUI:N - The attacker drives both the reclaim/swap-in traffic and the hotplug or suspend cycle itself; no victim action, mount, or file open is needed, and on hotplug-driven platforms the offline event occurs during normal operation.\nS:U - The freed `acomp_ctx` resources and the resulting corruption are entirely within the kernel's own memory and security authority, with no crossing of a VM, IOMMU, or sandbox boundary.\nC:H - `zswap_decompress()` memcpys into and then decompresses out of the freed 8 KB `acomp_ctx->buffer`, writing the result into the folio returned to userspace by the swap-in fault, so a groomed reallocation of that slab object leaks arbitrary kernel data into an attacker-readable page; the freed `acomp_req`/`crypto_acomp` are also read as live objects.\nI:H - `crypto_acomp_compress()` expands to `crypto_acomp_reqtfm(req)->compress(req)`, an indirect call through a function pointer loaded from the freed tfm, giving control-flow hijack after heap grooming; additionally the compressor writes up to `PAGE_SIZE * 2` of attacker-influenced output into the freed buffer and `acomp_request_set_params()` writes into the freed request.\nA:H - The use-after-free reliably oopses or panics the kernel, and `zswap_decompress()` carries two unconditional `BUG_ON()`s on the crypto result and `req->dlen` that fire immediately on garbage from freed structures — the bug was reported precisely as a crash by both Johannes Weiner and Sam Sun."}]}],"affected":[{"product":"Linux","vendor":"Linux","defaultStatus":"unaffected","repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","programFiles":["mm/zswap.c"],"versions":[{"version":"1ec3b5fe6eec782f4e5e0a80e4ce1909ffd5d161","lessThan":"8d29ff5d50304daa41dc3cfdda4a9d1e46cf5be1","status":"affected","versionType":"git"},{"version":"1ec3b5fe6eec782f4e5e0a80e4ce1909ffd5d161","lessThan":"12dcb0ef540629a281533f9dedc1b6b8e14cfb65","status":"affected","versionType":"git"}]},{"product":"Linux","vendor":"Linux","defaultStatus":"affected","repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","programFiles":["mm/zswap.c"],"versions":[{"version":"5.11","status":"affected"},{"version":"0","lessThan":"5.11","status":"unaffected","versionType":"semver"},{"version":"6.12.12","lessThanOrEqual":"6.12.*","status":"unaffected","versionType":"semver"},{"version":"6.13","lessThanOrEqual":"*","status":"unaffected","versionType":"original_commit_for_fix"}]}],"cpeApplicability":[{"nodes":[{"operator":"OR","negate":false,"cpeMatch":[{"vulnerable":true,"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionStartIncluding":"5.11","versionEndExcluding":"6.12.12"},{"vulnerable":true,"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionStartIncluding":"5.11","versionEndExcluding":"6.13"}]}]}],"references":[{"url":"https://git.kernel.org/stable/c/8d29ff5d50304daa41dc3cfdda4a9d1e46cf5be1"},{"url":"https://git.kernel.org/stable/c/12dcb0ef540629a281533f9dedc1b6b8e14cfb65"}],"title":"mm: zswap: properly synchronize freeing resources during CPU hotunplug","x_generator":{"engine":"bippy-1.2.0"}},"adp":[{"metrics":[{"cvssV3_1":{"scope":"UNCHANGED","version":"3.1","baseScore":7.8,"attackVector":"LOCAL","baseSeverity":"HIGH","vectorString":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H","integrityImpact":"HIGH","userInteraction":"NONE","attackComplexity":"LOW","availabilityImpact":"HIGH","privilegesRequired":"LOW","confidentialityImpact":"HIGH"}},{"other":{"type":"ssvc","content":{"id":"CVE-2025-21693","role":"CISA Coordinator","options":[{"Exploitation":"none"},{"Automatable":"no"},{"Technical Impact":"total"}],"version":"2.0.3","timestamp":"2025-02-10T17:10:07.856772Z"}}}],"problemTypes":[{"descriptions":[{"lang":"en","type":"CWE","cweId":"CWE-416","description":"CWE-416 Use After Free"}]}],"title":"CISA ADP Vulnrichment","providerMetadata":{"orgId":"134c704f-9b21-4f2e-91b3-4a467353bcc0","shortName":"CISA-ADP","dateUpdated":"2025-02-10T17:11:03.608Z"}}]}}