CVE-2025-21693 (GCVE-0-2025-21693)

Vulnerability from cvelistv5 – Published: 2025-02-10 15:58 – Updated: 2026-08-05 11:53
VLAI
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 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 cpus_read_lock() [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 synchronize_srcu() cannot be used in CPU hotplug notifiers [2]. Alternative fixes that were considered/attempted and could have worked: - Refcounting the per-CPU acomp_ctx. 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 acomp_ctx [3], but that's discouraged and is a much bigger hammer than needed, and could result in subtle performance issues. [1]https://lkml.kernel.org/20241219212437.2714151-1-yosryahmed@google.com/ [2]https://lkml.kernel.org/20250107074724.1756696-2-yosryahmed@google.com/ [3]https://lkml.kernel.org/20250107222236.2715883-2-yosryahmed@google.com/ [yosryahmed@google.com: remove comment]
Severity
7.8 (High)
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
SSVC
Exploitation: none Automatable: no Technical Impact: total
CISA Coordinator (v2.0.3)
CWE
Assigner
References
Impacted products
Vendor Product Version
Linux Linux Affected: 1ec3b5fe6eec782f4e5e0a80e4ce1909ffd5d161 , < 8d29ff5d50304daa41dc3cfdda4a9d1e46cf5be1 (git)
Affected: 1ec3b5fe6eec782f4e5e0a80e4ce1909ffd5d161 , < 12dcb0ef540629a281533f9dedc1b6b8e14cfb65 (git)
Create a notification for this product.
Linux Linux Affected: 5.11
Unaffected: 0 , < 5.11 (semver)
Unaffected: 6.12.12 , ≤ 6.12.* (semver)
Unaffected: 6.13 , ≤ * (original_commit_for_fix)
Create a notification for this product.
Show details on NVD website
To clipboard 

{
  "containers": {
    "adp": [
      {
        "metrics": [
          {
            "cvssV3_1": {
              "attackComplexity": "LOW",
              "attackVector": "LOCAL",
              "availabilityImpact": "HIGH",
              "baseScore": 7.8,
              "baseSeverity": "HIGH",
              "confidentialityImpact": "HIGH",
              "integrityImpact": "HIGH",
              "privilegesRequired": "LOW",
              "scope": "UNCHANGED",
              "userInteraction": "NONE",
              "vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
              "version": "3.1"
            }
          },
          {
            "other": {
              "content": {
                "id": "CVE-2025-21693",
                "options": [
                  {
                    "Exploitation": "none"
                  },
                  {
                    "Automatable": "no"
                  },
                  {
                    "Technical Impact": "total"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2025-02-10T17:10:07.856772Z",
                "version": "2.0.3"
              },
              "type": "ssvc"
            }
          }
        ],
        "problemTypes": [
          {
            "descriptions": [
              {
                "cweId": "CWE-416",
                "description": "CWE-416 Use After Free",
                "lang": "en",
                "type": "CWE"
              }
            ]
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2025-02-10T17:11:03.608Z",
          "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
          "shortName": "CISA-ADP"
        },
        "title": "CISA ADP Vulnrichment"
      }
    ],
    "cna": {
      "affected": [
        {
          "defaultStatus": "unaffected",
          "product": "Linux",
          "programFiles": [
            "mm/zswap.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "lessThan": "8d29ff5d50304daa41dc3cfdda4a9d1e46cf5be1",
              "status": "affected",
              "version": "1ec3b5fe6eec782f4e5e0a80e4ce1909ffd5d161",
              "versionType": "git"
            },
            {
              "lessThan": "12dcb0ef540629a281533f9dedc1b6b8e14cfb65",
              "status": "affected",
              "version": "1ec3b5fe6eec782f4e5e0a80e4ce1909ffd5d161",
              "versionType": "git"
            }
          ]
        },
        {
          "defaultStatus": "affected",
          "product": "Linux",
          "programFiles": [
            "mm/zswap.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "status": "affected",
              "version": "5.11"
            },
            {
              "lessThan": "5.11",
              "status": "unaffected",
              "version": "0",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.12.*",
              "status": "unaffected",
              "version": "6.12.12",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "*",
              "status": "unaffected",
              "version": "6.13",
              "versionType": "original_commit_for_fix"
            }
          ]
        }
      ],
      "cpeApplicability": [
        {
          "nodes": [
            {
              "cpeMatch": [
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.12.12",
                  "versionStartIncluding": "5.11",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.13",
                  "versionStartIncluding": "5.11",
                  "vulnerable": true
                }
              ],
              "negate": false,
              "operator": "OR"
            }
          ]
        }
      ],
      "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\u0027s 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": {
            "baseScore": 7.8,
            "baseSeverity": "HIGH",
            "vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
            "version": "3.1"
          },
          "scenarios": [
            {
              "lang": "en",
              "value": "AV:L - The UAF is reached through local memory-management activity \u2014 `madvise(MADV_PAGEOUT)`/reclaim driving `zswap_store()`\u2192`zswap_compress()` and swap-in faults driving `zswap_load()`\u2192`zswap_decompress()` \u2014 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\u0027s tasks have been pushed to other CPUs; the pre-fix per-CPU mutex additionally parks several attacker threads on the dying CPU\u0027s 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 \u2014 any user\u0027s own anonymous memory plus `madvise()` reaches it with no `capable()` check \u2014 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\u0027s 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-\u003ebuffer`, 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)-\u003ecompress(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-\u003edlen` that fire immediately on garbage from freed structures \u2014 the bug was reported precisely as a crash by both Johannes Weiner and Sam Sun."
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-08-05T11:53:39.821Z",
        "orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
        "shortName": "Linux"
      },
      "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"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
    "assignerShortName": "Linux",
    "cveId": "CVE-2025-21693",
    "datePublished": "2025-02-10T15:58:49.056Z",
    "dateReserved": "2024-12-29T08:45:45.742Z",
    "dateUpdated": "2026-08-05T11:53:39.821Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2",
  "vulnerability-lookup:meta": {
    "epss": {
      "cve": "CVE-2025-21693",
      "date": "2026-08-05",
      "epss": "0.002",
      "percentile": "0.09956"
    },
    "microsoft_vex": {
      "current_release_date": "2026-06-28T01:42:45.000Z",
      "cve": "CVE-2025-21693",
      "id": "msrc_CVE-2025-21693",
      "initial_release_date": "2025-02-02T00:00:00.000Z",
      "product_status:known_affected": "19",
      "source": "Microsoft CSAF VEX",
      "status": "final",
      "title": "mm: zswap: properly synchronize freeing resources during CPU hotunplug",
      "url": "https://msrc.microsoft.com/csaf/vex/2025/msrc_cve-2025-21693.json",
      "version": "15"
    },
    "nvd": "{\"cve\":{\"id\":\"CVE-2025-21693\",\"sourceIdentifier\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"published\":\"2025-02-10T16:15:38.883\",\"lastModified\":\"2026-06-17T08:44:02.480\",\"vulnStatus\":\"Modified\",\"cveTags\":[],\"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\u0027s 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]\"},{\"lang\":\"es\",\"value\":\"En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mm: zswap: sincronizar correctamente la liberaci\u00f3n de recursos durante la desconexi\u00f3n en caliente de la CPU En zswap_compress() y zswap_decompress(), se recupera y se utiliza en todo momento el acomp_ctx por CPU de la CPU actual al comienzo de la operaci\u00f3n. Sin embargo, dado que ni la preempci\u00f3n ni la migraci\u00f3n est\u00e1n deshabilitadas, es posible que la operaci\u00f3n contin\u00fae en una CPU diferente. Si se desconecta en caliente la CPU original mientras el acomp_ctx todav\u00eda est\u00e1 en uso, nos encontramos con un error de UAF ya que algunos de los recursos adjuntos al acomp_ctx se liberan durante la desconexi\u00f3n en caliente en zswap_cpu_comp_dead() (es decir, acomp_ctx.buffer, acomp_ctx.req o acomp_ctx.acomp). El problema se introdujo en el commit 1ec3b5fe6eec (\\\"mm/zswap: pasar a usar la API crypto_acomp para la aceleraci\u00f3n de hardware\\\") cuando se realiz\u00f3 el cambio a la API crypto_acomp. Antes de eso, el crypto_comp por CPU se recuperaba usando get_cpu_ptr() que deshabilita la preempci\u00f3n y se asegura de que la CPU no pueda irse de debajo de nosotros. La preempci\u00f3n no se puede deshabilitar con la API crypto_acomp ya que se necesita un contexto inactivo. Use acomp_ctx.mutex para sincronizar las devoluciones de llamadas hotplug de la CPU que asignan y liberan recursos con rutas de compresi\u00f3n/descompresi\u00f3n. Aseg\u00farese de que acomp_ctx.req sea NULL cuando se liberan los recursos. En las rutas de compresi\u00f3n/descompresi\u00f3n, verifique si acomp_ctx.req es NULL despu\u00e9s de adquirir el mutex (lo que significa que la CPU estaba fuera de l\u00ednea) y vuelva a intentarlo en la nueva CPU. La inicializaci\u00f3n de acomp_ctx.mutex se mueve de la devoluci\u00f3n de llamada hotplug de la CPU a la inicializaci\u00f3n del grupo donde pertenece (donde se asigna el mutex). Adem\u00e1s de agregar claridad, esto asegura que la conexi\u00f3n en caliente de la CPU no pueda reinicializar un mutex que ya est\u00e1 bloqueado por compresi\u00f3n/descompresi\u00f3n. Anteriormente se intent\u00f3 una soluci\u00f3n manteniendo pulsada la tecla cpus_read_lock() [1]. Esto habr\u00eda provocado un posible bloqueo, ya que es posible que el c\u00f3digo que ya mantiene el bloqueo caiga en recuperaci\u00f3n y entre en zswap (provocando un bloqueo). Tambi\u00e9n se intent\u00f3 una soluci\u00f3n utilizando SRCU para la sincronizaci\u00f3n, pero Johannes se\u00f1al\u00f3 que no se puede utilizarsynchronous_srcu() en los notificadores de conexi\u00f3n en caliente de la CPU [2]. Workarounds que se consideraron/intentaron y que podr\u00edan haber funcionado: - Refcounting el acomp_ctx por CPU. Esto implica complejidad en la gesti\u00f3n de la ejecuci\u00f3n entre el refcount que cae a cero en zswap_[de]compress() y el refcount que se reinicializa cuando la CPU est\u00e1 en l\u00ednea. - Deshabilitar la migraci\u00f3n antes de obtener el acomp_ctx por CPU [3], pero eso no se recomienda y es un martillo mucho m\u00e1s grande de lo necesario, y podr\u00eda dar lugar a problemas de rendimiento sutiles. [1]https://lkml.kernel.org/20241219212437.2714151-1-yosryahmed@google.com/ [2]https://lkml.kernel.org/20250107074724.1756696-2-yosryahmed@google.com/ [3]https://lkml.kernel.org/20250107222236.2715883-2-yosryahmed@google.com/ [yosryahmed@google.com: eliminar comentario] Enlace: https://lkml.kernel.org/r/CAJD7tkaxS1wjn+swugt8QCvQ-rVF5RZnjxwPGX17k8x9zSManA@mail.gmail.com\"}],\"affected\":[{\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"affectedData\":[{\"vendor\":\"Linux\",\"product\":\"Linux\",\"defaultStatus\":\"unaffected\",\"programFiles\":[\"mm/zswap.c\"],\"repo\":\"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git\",\"versions\":[{\"version\":\"1ec3b5fe6eec782f4e5e0a80e4ce1909ffd5d161\",\"lessThan\":\"8d29ff5d50304daa41dc3cfdda4a9d1e46cf5be1\",\"versionType\":\"git\",\"status\":\"affected\"},{\"version\":\"1ec3b5fe6eec782f4e5e0a80e4ce1909ffd5d161\",\"lessThan\":\"12dcb0ef540629a281533f9dedc1b6b8e14cfb65\",\"versionType\":\"git\",\"status\":\"affected\"}]},{\"vendor\":\"Linux\",\"product\":\"Linux\",\"defaultStatus\":\"affected\",\"programFiles\":[\"mm/zswap.c\"],\"repo\":\"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git\",\"versions\":[{\"version\":\"5.11\",\"status\":\"affected\"},{\"version\":\"0\",\"lessThan\":\"5.11\",\"versionType\":\"semver\",\"status\":\"unaffected\"},{\"version\":\"6.12.12\",\"lessThanOrEqual\":\"6.12.*\",\"versionType\":\"semver\",\"status\":\"unaffected\"},{\"version\":\"6.13\",\"lessThanOrEqual\":\"*\",\"versionType\":\"original_commit_for_fix\",\"status\":\"unaffected\"}]}]}],\"metrics\":{\"cvssMetricV31\":[{\"source\":\"134c704f-9b21-4f2e-91b3-4a467353bcc0\",\"type\":\"Secondary\",\"cvssData\":{\"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\",\"attackVector\":\"LOCAL\",\"attackComplexity\":\"LOW\",\"privilegesRequired\":\"LOW\",\"userInteraction\":\"NONE\",\"scope\":\"UNCHANGED\",\"confidentialityImpact\":\"HIGH\",\"integrityImpact\":\"HIGH\",\"availabilityImpact\":\"HIGH\"},\"exploitabilityScore\":1.8,\"impactScore\":5.9}],\"ssvcV203\":[{\"source\":\"134c704f-9b21-4f2e-91b3-4a467353bcc0\",\"ssvcData\":{\"timestamp\":\"2025-02-10T17:10:07.856772Z\",\"id\":\"CVE-2025-21693\",\"options\":[{\"exploitation\":\"none\"},{\"automatable\":\"no\"},{\"technicalImpact\":\"total\"}],\"role\":\"CISA Coordinator\",\"version\":\"2.0.3\"}}]},\"weaknesses\":[{\"source\":\"134c704f-9b21-4f2e-91b3-4a467353bcc0\",\"type\":\"Secondary\",\"description\":[{\"lang\":\"en\",\"value\":\"CWE-416\"}]}],\"configurations\":[{\"nodes\":[{\"operator\":\"OR\",\"negate\":false,\"cpeMatch\":[{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*\",\"versionStartIncluding\":\"5.11\",\"versionEndExcluding\":\"6.12.12\",\"matchCriteriaId\":\"1E1E1BB4-D8B4-4864-84DE-04926804B5EF\"},{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:6.13:rc1:*:*:*:*:*:*\",\"matchCriteriaId\":\"62567B3C-6CEE-46D0-BC2E-B3717FBF7D13\"},{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:6.13:rc2:*:*:*:*:*:*\",\"matchCriteriaId\":\"5A073481-106D-4B15-B4C7-FB0213B8E1D4\"},{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:6.13:rc3:*:*:*:*:*:*\",\"matchCriteriaId\":\"DE491969-75AE-4A6B-9A58-8FC5AF98798F\"},{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:6.13:rc4:*:*:*:*:*:*\",\"matchCriteriaId\":\"93C0660D-7FB8-4FBA-892A-B064BA71E49E\"},{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:6.13:rc5:*:*:*:*:*:*\",\"matchCriteriaId\":\"034C36A6-C481-41F3-AE9A-D116E5BE6895\"},{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:6.13:rc6:*:*:*:*:*:*\",\"matchCriteriaId\":\"8AF9DC49-2085-4FFB-A7E3-73DFAFECC7F2\"},{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:6.13:rc7:*:*:*:*:*:*\",\"matchCriteriaId\":\"5DFCDFB8-4FD0-465A-9076-D813D78FE51B\"}]}]}],\"references\":[{\"url\":\"https://git.kernel.org/stable/c/12dcb0ef540629a281533f9dedc1b6b8e14cfb65\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"tags\":[\"Patch\"]},{\"url\":\"https://git.kernel.org/stable/c/8d29ff5d50304daa41dc3cfdda4a9d1e46cf5be1\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"tags\":[\"Patch\"]}]}}",
    "redhat_vex": {
      "aggregate_severity": "Moderate",
      "current_release_date": "2026-07-24T03:35:30+00:00",
      "cve": "CVE-2025-21693",
      "id": "CVE-2025-21693",
      "initial_release_date": "2025-02-10T00:00:00+00:00",
      "product_status:fixed": "612",
      "product_status:known_affected": "50",
      "product_status:known_not_affected": "62",
      "source": "Red Hat CSAF VEX",
      "status": "final",
      "title": "kernel: mm: zswap: properly synchronize freeing resources during CPU hotunplug",
      "url": "https://security.access.redhat.com/data/csaf/v2/vex/2025/cve-2025-21693.json",
      "version": "3"
    },
    "suse_vex": {
      "aggregate_severity": "important",
      "current_release_date": "2026-07-31T01:20:49Z",
      "cve": "CVE-2025-21693",
      "id": "CVE-2025-21693",
      "initial_release_date": "2025-02-11T03:48:03Z",
      "product_status:known_affected": "369",
      "product_status:known_not_affected": "190",
      "product_status:recommended": "687",
      "source": "SUSE CSAF VEX",
      "status": "interim",
      "title": "SUSE CVE CVE-2025-21693",
      "url": "https://ftp.suse.com/pub/projects/security/csaf-vex/cve-2025-21693.json",
      "version": "56"
    },
    "vulnrichment": {
      "containers": "{\"adp\": [{\"title\": \"CISA ADP Vulnrichment\", \"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\"}]}], \"providerMetadata\": {\"orgId\": \"134c704f-9b21-4f2e-91b3-4a467353bcc0\", \"shortName\": \"CISA-ADP\", \"dateUpdated\": \"2025-02-10T17:10:20.821Z\"}}], \"cna\": {\"title\": \"mm: zswap: properly synchronize freeing resources during CPU hotunplug\", \"metrics\": [{\"cvssV3_1\": {\"version\": \"3.1\", \"baseScore\": 7.8, \"baseSeverity\": \"HIGH\", \"vectorString\": \"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H\"}, \"scenarios\": [{\"lang\": \"en\", \"value\": \"AV:L - The UAF is reached through local memory-management activity \\u2014 `madvise(MADV_PAGEOUT)`/reclaim driving `zswap_store()`\\u2192`zswap_compress()` and swap-in faults driving `zswap_load()`\\u2192`zswap_decompress()` \\u2014 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\u0027s tasks have been pushed to other CPUs; the pre-fix per-CPU mutex additionally parks several attacker threads on the dying CPU\u0027s 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 \\u2014 any user\u0027s own anonymous memory plus `madvise()` reaches it with no `capable()` check \\u2014 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\u0027s 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-\u003ebuffer`, 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)-\u003ecompress(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-\u003edlen` that fire immediately on garbage from freed structures \\u2014 the bug was reported precisely as a crash by both Johannes Weiner and Sam Sun.\"}]}], \"affected\": [{\"repo\": \"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git\", \"vendor\": \"Linux\", \"product\": \"Linux\", \"versions\": [{\"status\": \"affected\", \"version\": \"1ec3b5fe6eec782f4e5e0a80e4ce1909ffd5d161\", \"lessThan\": \"8d29ff5d50304daa41dc3cfdda4a9d1e46cf5be1\", \"versionType\": \"git\"}, {\"status\": \"affected\", \"version\": \"1ec3b5fe6eec782f4e5e0a80e4ce1909ffd5d161\", \"lessThan\": \"12dcb0ef540629a281533f9dedc1b6b8e14cfb65\", \"versionType\": \"git\"}], \"programFiles\": [\"mm/zswap.c\"], \"defaultStatus\": \"unaffected\"}, {\"repo\": \"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git\", \"vendor\": \"Linux\", \"product\": \"Linux\", \"versions\": [{\"status\": \"affected\", \"version\": \"5.11\"}, {\"status\": \"unaffected\", \"version\": \"0\", \"lessThan\": \"5.11\", \"versionType\": \"semver\"}, {\"status\": \"unaffected\", \"version\": \"6.12.12\", \"versionType\": \"semver\", \"lessThanOrEqual\": \"6.12.*\"}, {\"status\": \"unaffected\", \"version\": \"6.13\", \"versionType\": \"original_commit_for_fix\", \"lessThanOrEqual\": \"*\"}], \"programFiles\": [\"mm/zswap.c\"], \"defaultStatus\": \"affected\"}], \"references\": [{\"url\": \"https://git.kernel.org/stable/c/8d29ff5d50304daa41dc3cfdda4a9d1e46cf5be1\"}, {\"url\": \"https://git.kernel.org/stable/c/12dcb0ef540629a281533f9dedc1b6b8e14cfb65\"}], \"x_generator\": {\"engine\": \"bippy-1.2.0\"}, \"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\u0027s 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]\"}], \"cpeApplicability\": [{\"nodes\": [{\"negate\": false, \"cpeMatch\": [{\"criteria\": \"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*\", \"vulnerable\": true, \"versionEndExcluding\": \"6.12.12\", \"versionStartIncluding\": \"5.11\"}, {\"criteria\": \"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*\", \"vulnerable\": true, \"versionEndExcluding\": \"6.13\", \"versionStartIncluding\": \"5.11\"}], \"operator\": \"OR\"}]}], \"providerMetadata\": {\"orgId\": \"416baaa9-dc9f-4396-8d5f-8c081fb06d67\", \"shortName\": \"Linux\", \"dateUpdated\": \"2026-08-05T11:53:39.821Z\"}}}",
      "cveMetadata": "{\"cveId\": \"CVE-2025-21693\", \"state\": \"PUBLISHED\", \"dateUpdated\": \"2026-08-05T11:53:39.821Z\", \"dateReserved\": \"2024-12-29T08:45:45.742Z\", \"assignerOrgId\": \"416baaa9-dc9f-4396-8d5f-8c081fb06d67\", \"datePublished\": \"2025-02-10T15:58:49.056Z\", \"assignerShortName\": \"Linux\"}",
      "dataType": "CVE_RECORD",
      "dataVersion": "5.2"
    }
  }
}



Log in or create an account to share your comment.




Tags
Taxonomy of the tags.





Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

Sightings

Author Source Type Date Other

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.


Detection rules are retrieved from Rulezet.