fkie_cve-2024-42234
Vulnerability from fkie_nvd
Published
2024-08-07 16:15
Modified
2024-08-08 14:55
Severity ?
5.5 (Medium) - CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Summary
In the Linux kernel, the following vulnerability has been resolved: mm: fix crashes from deferred split racing folio migration Even on 6.10-rc6, I've been seeing elusive "Bad page state"s (often on flags when freeing, yet the flags shown are not bad: PG_locked had been set and cleared??), and VM_BUG_ON_PAGE(page_ref_count(page) == 0)s from deferred_split_scan()'s folio_put(), and a variety of other BUG and WARN symptoms implying double free by deferred split and large folio migration. 6.7 commit 9bcef5973e31 ("mm: memcg: fix split queue list crash when large folio migration") was right to fix the memcg-dependent locking broken in 85ce2c517ade ("memcontrol: only transfer the memcg data for migration"), but missed a subtlety of deferred_split_scan(): it moves folios to its own local list to work on them without split_queue_lock, during which time folio->_deferred_list is not empty, but even the "right" lock does nothing to secure the folio and the list it is on. Fortunately, deferred_split_scan() is careful to use folio_try_get(): so folio_migrate_mapping() can avoid the race by folio_undo_large_rmappable() while the old folio's reference count is temporarily frozen to 0 - adding such a freeze in the !mapping case too (originally, folio lock and unmapping and no swap cache left an anon folio unreachable, so no freezing was needed there: but the deferred split queue offers a way to reach it).
References
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/be9581ea8c058d81154251cb0695987098996cadPatch
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/fc7facce686b64201dbf0b9614cc1d0bfad70010Patch
Impacted products
Vendor Product Version
linux linux_kernel *


To clipboard 

{
  "configurations": [
    {
      "nodes": [
        {
          "cpeMatch": [
            {
              "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
              "matchCriteriaId": "AB2E8DEC-CFD5-4C2B-981D-E7E45A36C352",
              "versionEndExcluding": "6.9.10",
              "versionStartIncluding": "6.7",
              "vulnerable": true
            }
          ],
          "negate": false,
          "operator": "OR"
        }
      ]
    }
  ],
  "cveTags": [],
  "descriptions": [
    {
      "lang": "en",
      "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nmm: fix crashes from deferred split racing folio migration\n\nEven on 6.10-rc6, I\u0027ve been seeing elusive \"Bad page state\"s (often on\nflags when freeing, yet the flags shown are not bad: PG_locked had been\nset and cleared??), and VM_BUG_ON_PAGE(page_ref_count(page) == 0)s from\ndeferred_split_scan()\u0027s folio_put(), and a variety of other BUG and WARN\nsymptoms implying double free by deferred split and large folio migration.\n\n6.7 commit 9bcef5973e31 (\"mm: memcg: fix split queue list crash when large\nfolio migration\") was right to fix the memcg-dependent locking broken in\n85ce2c517ade (\"memcontrol: only transfer the memcg data for migration\"),\nbut missed a subtlety of deferred_split_scan(): it moves folios to its own\nlocal list to work on them without split_queue_lock, during which time\nfolio-\u003e_deferred_list is not empty, but even the \"right\" lock does nothing\nto secure the folio and the list it is on.\n\nFortunately, deferred_split_scan() is careful to use folio_try_get(): so\nfolio_migrate_mapping() can avoid the race by folio_undo_large_rmappable()\nwhile the old folio\u0027s reference count is temporarily frozen to 0 - adding\nsuch a freeze in the !mapping case too (originally, folio lock and\nunmapping and no swap cache left an anon folio unreachable, so no freezing\nwas needed there: but the deferred split queue offers a way to reach it)."
    },
    {
      "lang": "es",
      "value": "En el kernel de Linux, se resolvi\u00f3 la siguiente vulnerabilidad: mm: corrige fallas debido a la migraci\u00f3n diferida de folios de ejecuciones divididas Incluso en 6.10-rc6, he estado viendo \"estados de p\u00e1gina incorrectos\" esquivos (a menudo en indicadores al liberar, pero los indicadores mostrados no son malos: \u00bfPG_locked se hab\u00eda configurado y borrado?), y VM_BUG_ON_PAGE(page_ref_count(page) == 0)s de folio_put() de deferred_split_scan(), y una variedad de otros s\u00edntomas de ERROR y ADVERTENCIA que implican doble liberaci\u00f3n por divisi\u00f3n diferida y migraci\u00f3n de folios grandes. 6.7 el commit 9bcef5973e31 (\"mm: memcg: corregir el bloqueo de la lista de colas divididas cuando se migra un folio grande\") ten\u00eda raz\u00f3n al corregir el bloqueo dependiente de memcg roto en 85ce2c517ade (\"memcontrol: transferir solo los datos de memcg para la migraci\u00f3n\"), pero omiti\u00f3 una sutileza de deferred_split_scan(): mueve las publicaciones a su propia lista local para trabajar en ellas sin split_queue_lock, tiempo durante el cual folio-\u0026gt;_deferred_list no est\u00e1 vac\u00edo, pero ni siquiera el bloqueo \"derecho\" hace nada para proteger la publicaci\u00f3n y la lista en la que se encuentra. Afortunadamente, deferred_split_scan() tiene cuidado al usar folio_try_get(): por lo que folio_migrate_mapping() puede evitar la ejecuci\u00f3n mediante folio_undo_large_rmappable() mientras el recuento de referencias de la publicaci\u00f3n anterior se congela temporalmente en 0; agregando dicha congelaci\u00f3n tambi\u00e9n en el caso de !mapping (originalmente, El bloqueo y la desasignaci\u00f3n de folios y la falta de cach\u00e9 de intercambio dejaron un folio an\u00f3nimo inalcanzable, por lo que no fue necesario congelarlo all\u00ed: pero la cola dividida diferida ofrece una forma de acceder a \u00e9l)."
    }
  ],
  "id": "CVE-2024-42234",
  "lastModified": "2024-08-08T14:55:29.913",
  "metrics": {
    "cvssMetricV31": [
      {
        "cvssData": {
          "attackComplexity": "LOW",
          "attackVector": "LOCAL",
          "availabilityImpact": "HIGH",
          "baseScore": 5.5,
          "baseSeverity": "MEDIUM",
          "confidentialityImpact": "NONE",
          "integrityImpact": "NONE",
          "privilegesRequired": "LOW",
          "scope": "UNCHANGED",
          "userInteraction": "NONE",
          "vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
          "version": "3.1"
        },
        "exploitabilityScore": 1.8,
        "impactScore": 3.6,
        "source": "nvd@nist.gov",
        "type": "Primary"
      }
    ]
  },
  "published": "2024-08-07T16:15:46.390",
  "references": [
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "tags": [
        "Patch"
      ],
      "url": "https://git.kernel.org/stable/c/be9581ea8c058d81154251cb0695987098996cad"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "tags": [
        "Patch"
      ],
      "url": "https://git.kernel.org/stable/c/fc7facce686b64201dbf0b9614cc1d0bfad70010"
    }
  ],
  "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
  "vulnStatus": "Analyzed",
  "weaknesses": [
    {
      "description": [
        {
          "lang": "en",
          "value": "CWE-415"
        }
      ],
      "source": "nvd@nist.gov",
      "type": "Primary"
    }
  ]
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.




Sightings

Author Source Type Date

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or seen somewhere by the user.
  • Confirmed: The vulnerability is confirmed from an analyst perspective.
  • Exploited: This vulnerability was exploited and seen by the user reporting the sighting.
  • Patched: This vulnerability was successfully patched by the user reporting the sighting.
  • Not exploited: This vulnerability was not exploited or seen by the user reporting the sighting.
  • Not confirmed: The user expresses doubt about the veracity of the vulnerability.
  • Not patched: This vulnerability was not successfully patched by the user reporting the sighting.