Skip to content
Heist/ feed
Back to feed
HighFix available

mm: zswap: properly synchronize freeing resources during CPU hotunplug

Type: advisorySources: OSV

In the Linux kernel, the following vulnerability has been resolved: mm: zswap: properly synchronize freeing resources during CPU hotunplug In zswap_compress() and zswap_decompress(), the per-CPU acomp_ctx 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 acomp_ctx is still in use, we run into a UAF bug as some of the resources attached to the acomp_ctx are freed during hotunplug in zswap_cpu_comp_dead() (i.e. acomp_ctx.buffer, acomp_ctx.req, or acomp_ctx.acomp). The problem was introduced in commit 1ec3b5fe6eec ("mm/zswap: move to use crypto_acomp API for hardware acceleration") when the switch to the crypto_acomp API was made. Prior to that, the per-CPU crypto_comp was retrieved using get_cpu_ptr() which disables preemption and makes sure the CPU cannot go away from under us. Preemption cannot be disabled with the crypto_acomp API as a sleepable context is needed. Use the acomp_ctx.mutex to synchronize CPU hotplug callbacks allocating and freeing resources with compression/decompression paths. Make sure that acomp_ctx.req is NULL when the resources are freed. In the compression/decompression paths, check if acomp_ctx.req is NULL after acquiring the mutex (meaning the CPU was offlined) and retry on the new CPU. The initialization of acomp_ctx.mutex is moved from the CPU

Products
Kernel
Affected versions
Not specified
Fixed versions
6.12.12
CVEs
CVE-2025-21693
Confirmed fixed CVEs
Not specified
Updated in this feed
5 Nov 2026, 17:51 UTC · Revision 1

Source evidence

mm: zswap: properly synchronize freeing resources during CPU hotunplug

core-osv · Original source

Published 10 Feb 2025, 15:58 UTC

In the Linux kernel, the following vulnerability has been resolved: mm: zswap: properly synchronize freeing resources during CPU hotunplug In zswap_compress() and zswap_decompress(), the per-CPU acomp_ctx 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 acomp_ctx is still in use, we run into a UAF bug as some of the resources attached to the acomp_ctx are freed during hotunplug in zswap_cpu_comp_dead() (i.e. acomp_ctx.buffer, acomp_ctx.req, or acomp_ctx.acomp). The problem was introduced in commit 1ec3b5fe6eec ("mm/zswap: move to use crypto_acomp API for hardware acceleration") when the switch to the crypto_acomp API was made. Prior to that, the per-CPU crypto_comp was retrieved using get_cpu_ptr() which disables preemption and makes sure the CPU cannot go away from under us. Preemption cannot be disabled with the crypto_acomp API as a sleepable context is needed. Use the acomp_ctx.mutex to synchronize CPU hotplug callbacks allocating and freeing resources with compression/decompression paths. Make sure that acomp_ctx.req is NULL when the resources are freed. In the compression/decompression paths, check if acomp_ctx.req is NULL after acquiring the mutex (meaning the CPU was offlined) and retry on the new CPU. The initialization of acomp_ctx.mutex is moved from the CPU

osv:CVE-2025-21693

Kernel

Fixed versions: 6.12.12

Complete source record
{
  "id": "ecaa374d794cf606695e1bcd3ff6ea0c1f70c76452765c48751ae78e08925c03",
  "url": "https://osv.dev/vulnerability/CVE-2025-21693",
  "method": "structured",
  "payload": {
    "kind": "advisory",
    "title": "mm: zswap: properly synchronize freeing resources during CPU hotunplug",
    "summary": "In the Linux kernel, the following vulnerability has been resolved: mm: zswap: properly synchronize freeing resources during CPU hotunplug In zswap_compress() and zswap_decompress(), the per-CPU acomp_ctx 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 acomp_ctx is still in use, we run into a UAF bug as some of the resources attached to the acomp_ctx are freed during hotunplug in zswap_cpu_comp_dead() (i.e. acomp_ctx.buffer, acomp_ctx.req, or acomp_ctx.acomp). The problem was introduced in commit 1ec3b5fe6eec (\"mm/zswap: move to use crypto_acomp API for hardware acceleration\") when the switch to the crypto_acomp API was made. Prior to that, the per-CPU crypto_comp was retrieved using get_cpu_ptr() which disables preemption and makes sure the CPU cannot go away from under us. Preemption cannot be disabled with the crypto_acomp API as a sleepable context is needed. Use the acomp_ctx.mutex to synchronize CPU hotplug callbacks allocating and freeing resources with compression/decompression paths. Make sure that acomp_ctx.req is NULL when the resources are freed. In the compression/decompression paths, check if acomp_ctx.req is NULL after acquiring the mutex (meaning the CPU was offlined) and retry on the new CPU. The initialization of acomp_ctx.mutex is moved from the CPU ",
    "evidence": "osv:CVE-2025-21693",
    "products": [
      {
        "name": {
          "value": "Kernel",
          "evidence": "/affected/1/package/name"
        },
        "prerequisites": [],
        "fixed_versions": [
          {
            "value": "6.12.12",
            "evidence": "/affected/1/ranges"
          }
        ],
        "affected_versions": []
      }
    ],
    "severity": "high",
    "structured": {
      "id": "CVE-2025-21693",
      "aliases": [
        "CVE-2025-21693"
      ],
      "metrics": [
        {
          "type": "CVSS_V3",
          "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H"
        }
      ],
      "affected": [
        {
          "ranges": [
            {
              "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
              "type": "GIT",
              "events": [
                {
                  "introduced": "1ec3b5fe6eec782f4e5e0a80e4ce1909ffd5d161"
                },
                {
                  "fixed": "8d29ff5d50304daa41dc3cfdda4a9d1e46cf5be1"
                },
                {
                  "fixed": "12dcb0ef540629a281533f9dedc1b6b8e14cfb65"
                }
              ]
            }
          ],
          "database_specific": {
            "source": "https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2025-21693.json"
          }
        },
        {
          "ranges": [
            {
              "type": "ECOSYSTEM",
              "events": [
                {
                  "introduced": "5.11.0"
                },
                {
                  "fixed": "6.12.12"
                }
              ]
            }
          ],
          "package": {
            "name": "Kernel",
            "ecosystem": "Linux"
          },
          "database_specific": {
            "source": "https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2025-21693.json"
          }
        }
      ],
      "modified": "2026-10-28T02:30:44.775455307Z",
      "provider": "osv",
      "references": [
        "https://git.kernel.org/stable/c/12dcb0ef540629a281533f9dedc1b6b8e14cfb65",
        "https://git.kernel.org/stable/c/8d29ff5d50304daa41dc3cfdda4a9d1e46cf5be1",
        "https://github.com/CVEProject/cvelistV5/tree/main/cves/2025/21xxx/CVE-2025-21693.json",
        "https://nvd.nist.gov/vuln/detail/CVE-2025-21693",
        "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git"
      ],
      "provider_metadata": {
        "cna_assigner": "Linux",
        "osv_generated_from": "https://github.com/CVEProject/cvelistV5/tree/main/cves/2025/21xxx/CVE-2025-21693.json"
      }
    },
    "related_cves": [
      {
        "value": "CVE-2025-21693",
        "evidence": "/id"
      }
    ],
    "security_relevant": true,
    "severity_evidence": "/severity/0/score"
  },
  "source_id": "core-osv",
  "document_id": 512594,
  "published_at": "2025-02-10T15:58:49.056+00:00"
}