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

Vulnerability from cvelistv5 – Published: 2025-02-10 15:58 – Updated: 2026-05-11 21:04
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
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]"
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-05-11T21:04:35.992Z",
        "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-05-11T21:04:35.992Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2",
  "vulnerability-lookup:meta": {
    "epss": {
      "cve": "CVE-2025-21693",
      "date": "2026-05-21",
      "epss": "0.00024",
      "percentile": "0.06827"
    },
    "nvd": "{\"cve\":{\"id\":\"CVE-2025-21693\",\"sourceIdentifier\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"published\":\"2025-02-10T16:15:38.883\",\"lastModified\":\"2025-04-16T19:15:52.933\",\"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\"}],\"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}]},\"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\"]}]}}",
    "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\", \"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.0.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]\"}], \"providerMetadata\": {\"orgId\": \"416baaa9-dc9f-4396-8d5f-8c081fb06d67\", \"shortName\": \"Linux\", \"dateUpdated\": \"2025-04-16T18:16:51.903Z\"}}}",
      "cveMetadata": "{\"cveId\": \"CVE-2025-21693\", \"state\": \"PUBLISHED\", \"dateUpdated\": \"2025-04-16T18:16:51.903Z\", \"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.1"
    }
  }
}


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.