cve-2024-50220
Vulnerability from cvelistv5
Published
2024-11-09 10:14
Modified
2024-12-19 09:35
Severity ?
Summary
In the Linux kernel, the following vulnerability has been resolved: fork: do not invoke uffd on fork if error occurs Patch series "fork: do not expose incomplete mm on fork". During fork we may place the virtual memory address space into an inconsistent state before the fork operation is complete. In addition, we may encounter an error during the fork operation that indicates that the virtual memory address space is invalidated. As a result, we should not be exposing it in any way to external machinery that might interact with the mm or VMAs, machinery that is not designed to deal with incomplete state. We specifically update the fork logic to defer khugepaged and ksm to the end of the operation and only to be invoked if no error arose, and disallow uffd from observing fork events should an error have occurred. This patch (of 2): Currently on fork we expose the virtual address space of a process to userland unconditionally if uffd is registered in VMAs, regardless of whether an error arose in the fork. This is performed in dup_userfaultfd_complete() which is invoked unconditionally, and performs two duties - invoking registered handlers for the UFFD_EVENT_FORK event via dup_fctx(), and clearing down userfaultfd_fork_ctx objects established in dup_userfaultfd(). This is problematic, because the virtual address space may not yet be correctly initialised if an error arose. The change in commit d24062914837 ("fork: use __mt_dup() to duplicate maple tree in dup_mmap()") makes this more pertinent as we may be in a state where entries in the maple tree are not yet consistent. We address this by, on fork error, ensuring that we roll back state that we would otherwise expect to clean up through the event being handled by userland and perform the memory freeing duty otherwise performed by dup_userfaultfd_complete(). We do this by implementing a new function, dup_userfaultfd_fail(), which performs the same loop, only decrementing reference counts. Note that we perform mmgrab() on the parent and child mm's, however userfaultfd_ctx_put() will mmdrop() this once the reference count drops to zero, so we will avoid memory leaks correctly here.
References
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/92b472945dbf8abc020e9259c0088026f7027dfc
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/f64e67e5d3a45a4a04286c47afade4b518acd47b
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://project-zero.issues.chromium.org/issues/373391951
Impacted products
Vendor Product Version
Linux Linux Version: d2406291483775ecddaee929231a39c70c08fda2
Version: d2406291483775ecddaee929231a39c70c08fda2
 Create a notification for this product.
   Linux Linux Version: 6.8
 Create a notification for this product.
Show details on NVD website

To clipboard 

{
  "containers": {
    "cna": {
      "affected": [
        {
          "defaultStatus": "unaffected",
          "product": "Linux",
          "programFiles": [
            "fs/userfaultfd.c",
            "include/linux/userfaultfd_k.h",
            "kernel/fork.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "lessThan": "92b472945dbf8abc020e9259c0088026f7027dfc",
              "status": "affected",
              "version": "d2406291483775ecddaee929231a39c70c08fda2",
              "versionType": "git"
            },
            {
              "lessThan": "f64e67e5d3a45a4a04286c47afade4b518acd47b",
              "status": "affected",
              "version": "d2406291483775ecddaee929231a39c70c08fda2",
              "versionType": "git"
            }
          ]
        },
        {
          "defaultStatus": "affected",
          "product": "Linux",
          "programFiles": [
            "fs/userfaultfd.c",
            "include/linux/userfaultfd_k.h",
            "kernel/fork.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "status": "affected",
              "version": "6.8"
            },
            {
              "lessThan": "6.8",
              "status": "unaffected",
              "version": "0",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.11.*",
              "status": "unaffected",
              "version": "6.11.7",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "*",
              "status": "unaffected",
              "version": "6.12",
              "versionType": "original_commit_for_fix"
            }
          ]
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nfork: do not invoke uffd on fork if error occurs\n\nPatch series \"fork: do not expose incomplete mm on fork\".\n\nDuring fork we may place the virtual memory address space into an\ninconsistent state before the fork operation is complete.\n\nIn addition, we may encounter an error during the fork operation that\nindicates that the virtual memory address space is invalidated.\n\nAs a result, we should not be exposing it in any way to external machinery\nthat might interact with the mm or VMAs, machinery that is not designed to\ndeal with incomplete state.\n\nWe specifically update the fork logic to defer khugepaged and ksm to the\nend of the operation and only to be invoked if no error arose, and\ndisallow uffd from observing fork events should an error have occurred.\n\n\nThis patch (of 2):\n\nCurrently on fork we expose the virtual address space of a process to\nuserland unconditionally if uffd is registered in VMAs, regardless of\nwhether an error arose in the fork.\n\nThis is performed in dup_userfaultfd_complete() which is invoked\nunconditionally, and performs two duties - invoking registered handlers\nfor the UFFD_EVENT_FORK event via dup_fctx(), and clearing down\nuserfaultfd_fork_ctx objects established in dup_userfaultfd().\n\nThis is problematic, because the virtual address space may not yet be\ncorrectly initialised if an error arose.\n\nThe change in commit d24062914837 (\"fork: use __mt_dup() to duplicate\nmaple tree in dup_mmap()\") makes this more pertinent as we may be in a\nstate where entries in the maple tree are not yet consistent.\n\nWe address this by, on fork error, ensuring that we roll back state that\nwe would otherwise expect to clean up through the event being handled by\nuserland and perform the memory freeing duty otherwise performed by\ndup_userfaultfd_complete().\n\nWe do this by implementing a new function, dup_userfaultfd_fail(), which\nperforms the same loop, only decrementing reference counts.\n\nNote that we perform mmgrab() on the parent and child mm\u0027s, however\nuserfaultfd_ctx_put() will mmdrop() this once the reference count drops to\nzero, so we will avoid memory leaks correctly here."
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2024-12-19T09:35:46.769Z",
        "orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
        "shortName": "Linux"
      },
      "references": [
        {
          "url": "https://git.kernel.org/stable/c/92b472945dbf8abc020e9259c0088026f7027dfc"
        },
        {
          "url": "https://git.kernel.org/stable/c/f64e67e5d3a45a4a04286c47afade4b518acd47b"
        },
        {
          "url": "https://project-zero.issues.chromium.org/issues/373391951"
        }
      ],
      "title": "fork: do not invoke uffd on fork if error occurs",
      "x_generator": {
        "engine": "bippy-5f407fcff5a0"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
    "assignerShortName": "Linux",
    "cveId": "CVE-2024-50220",
    "datePublished": "2024-11-09T10:14:31.548Z",
    "dateReserved": "2024-10-21T19:36:19.973Z",
    "dateUpdated": "2024-12-19T09:35:46.769Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.1",
  "vulnerability-lookup:meta": {
    "nvd": "{\"cve\":{\"id\":\"CVE-2024-50220\",\"sourceIdentifier\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"published\":\"2024-11-09T11:15:07.487\",\"lastModified\":\"2024-12-09T22:15:22.400\",\"vulnStatus\":\"Awaiting Analysis\",\"cveTags\":[],\"descriptions\":[{\"lang\":\"en\",\"value\":\"In the Linux kernel, the following vulnerability has been resolved:\\n\\nfork: do not invoke uffd on fork if error occurs\\n\\nPatch series \\\"fork: do not expose incomplete mm on fork\\\".\\n\\nDuring fork we may place the virtual memory address space into an\\ninconsistent state before the fork operation is complete.\\n\\nIn addition, we may encounter an error during the fork operation that\\nindicates that the virtual memory address space is invalidated.\\n\\nAs a result, we should not be exposing it in any way to external machinery\\nthat might interact with the mm or VMAs, machinery that is not designed to\\ndeal with incomplete state.\\n\\nWe specifically update the fork logic to defer khugepaged and ksm to the\\nend of the operation and only to be invoked if no error arose, and\\ndisallow uffd from observing fork events should an error have occurred.\\n\\n\\nThis patch (of 2):\\n\\nCurrently on fork we expose the virtual address space of a process to\\nuserland unconditionally if uffd is registered in VMAs, regardless of\\nwhether an error arose in the fork.\\n\\nThis is performed in dup_userfaultfd_complete() which is invoked\\nunconditionally, and performs two duties - invoking registered handlers\\nfor the UFFD_EVENT_FORK event via dup_fctx(), and clearing down\\nuserfaultfd_fork_ctx objects established in dup_userfaultfd().\\n\\nThis is problematic, because the virtual address space may not yet be\\ncorrectly initialised if an error arose.\\n\\nThe change in commit d24062914837 (\\\"fork: use __mt_dup() to duplicate\\nmaple tree in dup_mmap()\\\") makes this more pertinent as we may be in a\\nstate where entries in the maple tree are not yet consistent.\\n\\nWe address this by, on fork error, ensuring that we roll back state that\\nwe would otherwise expect to clean up through the event being handled by\\nuserland and perform the memory freeing duty otherwise performed by\\ndup_userfaultfd_complete().\\n\\nWe do this by implementing a new function, dup_userfaultfd_fail(), which\\nperforms the same loop, only decrementing reference counts.\\n\\nNote that we perform mmgrab() on the parent and child mm\u0027s, however\\nuserfaultfd_ctx_put() will mmdrop() this once the reference count drops to\\nzero, so we will avoid memory leaks correctly here.\"},{\"lang\":\"es\",\"value\":\"En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: fork: no invocar uffd en fork si ocurre un error Serie de parches \\\"fork: no exponer mm incompleto en fork\\\". Durante fork podemos colocar el espacio de direcciones de memoria virtual en un estado inconsistente antes de que se complete la operaci\u00f3n de fork. Adem\u00e1s, podemos encontrar un error durante la operaci\u00f3n de fork que indique que el espacio de direcciones de memoria virtual est\u00e1 invalidado. Como resultado, no deber\u00edamos exponerlo de ninguna manera a maquinaria externa que pueda interactuar con mm o VMAs, maquinaria que no est\u00e1 dise\u00f1ada para lidiar con estado incompleto. Actualizamos espec\u00edficamente la l\u00f3gica de fork para diferir khugepaged y ksm hasta el final de la operaci\u00f3n y solo para ser invocados si no surgi\u00f3 ning\u00fan error, y no permitimos que uffd observe eventos de fork si se ha producido un error. Este parche (de 2): Actualmente en fork exponemos el espacio de direcciones virtuales de un proceso al espacio de usuario incondicionalmente si uffd est\u00e1 registrado en VMAs, independientemente de si surgi\u00f3 un error en la bifurcaci\u00f3n. Esto se realiza en dup_userfaultfd_complete(), que se invoca de manera incondicional y realiza dos tareas: invocar controladores registrados para el evento UFFD_EVENT_FORK a trav\u00e9s de dup_fctx() y limpiar los objetos userfaultfd_fork_ctx establecidos en dup_userfaultfd(). Esto es problem\u00e1tico, porque el espacio de direcciones virtuales puede no estar inicializado correctamente si surge un error. El cambio en el commit d24062914837 (\\\"fork: use __mt_dup() to duplicate maple tree in dup_mmap()\\\") hace que esto sea m\u00e1s pertinente, ya que podemos estar en un estado en el que las entradas en el \u00e1rbol de maple a\u00fan no sean consistentes. Abordamos esto, en caso de error de fork, asegur\u00e1ndonos de revertir el estado que de otra manera esperar\u00edamos limpiar a trav\u00e9s del evento que est\u00e1 siendo manejado por el espacio de usuario y realizar la tarea de liberaci\u00f3n de memoria que de otra manera realizar\u00eda dup_userfaultfd_complete(). Para ello, implementamos una nueva funci\u00f3n, dup_userfaultfd_fail(), que realiza el mismo bucle, pero disminuyendo el recuento de referencias. Tenga en cuenta que ejecutamos mmgrab() en los mm principales y secundarios, sin embargo, userfaultfd_ctx_put() ejecutar\u00e1 mmdrop() una vez que el recuento de referencias baje a cero, por lo que evitaremos fugas de memoria correctamente aqu\u00ed.\"}],\"metrics\":{},\"references\":[{\"url\":\"https://git.kernel.org/stable/c/92b472945dbf8abc020e9259c0088026f7027dfc\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\"},{\"url\":\"https://git.kernel.org/stable/c/f64e67e5d3a45a4a04286c47afade4b518acd47b\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\"},{\"url\":\"https://project-zero.issues.chromium.org/issues/373391951\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\"}]}}"
  }
}


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.