{"uuid": "980ad3d7-7d33-4a39-af1f-5ae820169b26", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "2a075640-a300-48a4-bb44-bc6130783b9b", "vulnerability": "CVE-2025-21693", "type": "seen", "source": "https://t.me/cvedetector/17572", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2025-21693 - Linux Kernel zswap Crypto Accomp API CPU Hotplug UAF\", \n  \"Content\": \"CVE ID : CVE-2025-21693 \nPublished : Feb. 10, 2025, 4:15 p.m. | 1\u00a0hour, 27\u00a0minutes ago \nDescription : 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]  \n[2]  \n[3]  \n  \n[yosryahmed@google.com: remove comment]  \n  Link:  \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"10 Feb 2025\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2025-02-10T18:45:47.000000Z"}