GSD-2024-26646

Vulnerability from gsd - Updated: 2024-02-20 06:02
Details
In the Linux kernel, the following vulnerability has been resolved: thermal: intel: hfi: Add syscore callbacks for system-wide PM The kernel allocates a memory buffer and provides its location to the hardware, which uses it to update the HFI table. This allocation occurs during boot and remains constant throughout runtime. When resuming from hibernation, the restore kernel allocates a second memory buffer and reprograms the HFI hardware with the new location as part of a normal boot. The location of the second memory buffer may differ from the one allocated by the image kernel. When the restore kernel transfers control to the image kernel, its HFI buffer becomes invalid, potentially leading to memory corruption if the hardware writes to it (the hardware continues to use the buffer from the restore kernel). It is also possible that the hardware "forgets" the address of the memory buffer when resuming from "deep" suspend. Memory corruption may also occur in such a scenario. To prevent the described memory corruption, disable HFI when preparing to suspend or hibernate. Enable it when resuming. Add syscore callbacks to handle the package of the boot CPU (packages of non-boot CPUs are handled via CPU offline). Syscore ops always run on the boot CPU. Additionally, HFI only needs to be disabled during "deep" suspend and hibernation. Syscore ops only run in these cases. [ rjw: Comment adjustment, subject and changelog edits ]
Aliases

{
  "gsd": {
    "metadata": {
      "exploitCode": "unknown",
      "remediation": "unknown",
      "reportConfidence": "confirmed",
      "type": "vulnerability"
    },
    "osvSchema": {
      "aliases": [
        "CVE-2024-26646"
      ],
      "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nthermal: intel: hfi: Add syscore callbacks for system-wide PM\n\nThe kernel allocates a memory buffer and provides its location to the\nhardware, which uses it to update the HFI table. This allocation occurs\nduring boot and remains constant throughout runtime.\n\nWhen resuming from hibernation, the restore kernel allocates a second\nmemory buffer and reprograms the HFI hardware with the new location as\npart of a normal boot. The location of the second memory buffer may\ndiffer from the one allocated by the image kernel.\n\nWhen the restore kernel transfers control to the image kernel, its HFI\nbuffer becomes invalid, potentially leading to memory corruption if the\nhardware writes to it (the hardware continues to use the buffer from the\nrestore kernel).\n\nIt is also possible that the hardware \"forgets\" the address of the memory\nbuffer when resuming from \"deep\" suspend. Memory corruption may also occur\nin such a scenario.\n\nTo prevent the described memory corruption, disable HFI when preparing to\nsuspend or hibernate. Enable it when resuming.\n\nAdd syscore callbacks to handle the package of the boot CPU (packages of\nnon-boot CPUs are handled via CPU offline). Syscore ops always run on the\nboot CPU. Additionally, HFI only needs to be disabled during \"deep\" suspend\nand hibernation. Syscore ops only run in these cases.\n\n[ rjw: Comment adjustment, subject and changelog edits ]",
      "id": "GSD-2024-26646",
      "modified": "2024-02-20T06:02:29.229188Z",
      "schema_version": "1.4.0"
    }
  },
  "namespaces": {
    "cve.org": {
      "CVE_data_meta": {
        "ASSIGNER": "cve@kernel.org",
        "ID": "CVE-2024-26646",
        "STATE": "PUBLIC"
      },
      "affects": {
        "vendor": {
          "vendor_data": [
            {
              "product": {
                "product_data": [
                  {
                    "product_name": "Linux",
                    "version": {
                      "version_data": [
                        {
                          "version_affected": "\u003c",
                          "version_name": "1da177e4c3f4",
                          "version_value": "28f010dc50df"
                        },
                        {
                          "version_value": "not down converted",
                          "x_cve_json_5_version_data": {
                            "defaultStatus": "affected",
                            "versions": [
                              {
                                "lessThanOrEqual": "6.1.*",
                                "status": "unaffected",
                                "version": "6.1.76",
                                "versionType": "custom"
                              },
                              {
                                "lessThanOrEqual": "6.6.*",
                                "status": "unaffected",
                                "version": "6.6.15",
                                "versionType": "custom"
                              },
                              {
                                "lessThanOrEqual": "6.7.*",
                                "status": "unaffected",
                                "version": "6.7.3",
                                "versionType": "custom"
                              },
                              {
                                "lessThanOrEqual": "*",
                                "status": "unaffected",
                                "version": "6.8",
                                "versionType": "original_commit_for_fix"
                              }
                            ]
                          }
                        }
                      ]
                    }
                  }
                ]
              },
              "vendor_name": "Linux"
            }
          ]
        }
      },
      "data_format": "MITRE",
      "data_type": "CVE",
      "data_version": "4.0",
      "description": {
        "description_data": [
          {
            "lang": "eng",
            "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nthermal: intel: hfi: Add syscore callbacks for system-wide PM\n\nThe kernel allocates a memory buffer and provides its location to the\nhardware, which uses it to update the HFI table. This allocation occurs\nduring boot and remains constant throughout runtime.\n\nWhen resuming from hibernation, the restore kernel allocates a second\nmemory buffer and reprograms the HFI hardware with the new location as\npart of a normal boot. The location of the second memory buffer may\ndiffer from the one allocated by the image kernel.\n\nWhen the restore kernel transfers control to the image kernel, its HFI\nbuffer becomes invalid, potentially leading to memory corruption if the\nhardware writes to it (the hardware continues to use the buffer from the\nrestore kernel).\n\nIt is also possible that the hardware \"forgets\" the address of the memory\nbuffer when resuming from \"deep\" suspend. Memory corruption may also occur\nin such a scenario.\n\nTo prevent the described memory corruption, disable HFI when preparing to\nsuspend or hibernate. Enable it when resuming.\n\nAdd syscore callbacks to handle the package of the boot CPU (packages of\nnon-boot CPUs are handled via CPU offline). Syscore ops always run on the\nboot CPU. Additionally, HFI only needs to be disabled during \"deep\" suspend\nand hibernation. Syscore ops only run in these cases.\n\n[ rjw: Comment adjustment, subject and changelog edits ]"
          }
        ]
      },
      "generator": {
        "engine": "bippy-b4257b672505"
      },
      "problemtype": {
        "problemtype_data": [
          {
            "description": [
              {
                "lang": "eng",
                "value": "n/a"
              }
            ]
          }
        ]
      },
      "references": {
        "reference_data": [
          {
            "name": "https://git.kernel.org/stable/c/28f010dc50df0f7987c04112114fcfa7e0803566",
            "refsource": "MISC",
            "url": "https://git.kernel.org/stable/c/28f010dc50df0f7987c04112114fcfa7e0803566"
          },
          {
            "name": "https://git.kernel.org/stable/c/019ccc66d56a696a4dfee3bfa2f04d0a7c3d89ee",
            "refsource": "MISC",
            "url": "https://git.kernel.org/stable/c/019ccc66d56a696a4dfee3bfa2f04d0a7c3d89ee"
          },
          {
            "name": "https://git.kernel.org/stable/c/c9d6d63b6c03afaa6f185df249af693a7939577c",
            "refsource": "MISC",
            "url": "https://git.kernel.org/stable/c/c9d6d63b6c03afaa6f185df249af693a7939577c"
          },
          {
            "name": "https://git.kernel.org/stable/c/97566d09fd02d2ab329774bb89a2cdf2267e86d9",
            "refsource": "MISC",
            "url": "https://git.kernel.org/stable/c/97566d09fd02d2ab329774bb89a2cdf2267e86d9"
          }
        ]
      }
    },
    "nvd.nist.gov": {
      "cve": {
        "descriptions": [
          {
            "lang": "en",
            "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nthermal: intel: hfi: Add syscore callbacks for system-wide PM\n\nThe kernel allocates a memory buffer and provides its location to the\nhardware, which uses it to update the HFI table. This allocation occurs\nduring boot and remains constant throughout runtime.\n\nWhen resuming from hibernation, the restore kernel allocates a second\nmemory buffer and reprograms the HFI hardware with the new location as\npart of a normal boot. The location of the second memory buffer may\ndiffer from the one allocated by the image kernel.\n\nWhen the restore kernel transfers control to the image kernel, its HFI\nbuffer becomes invalid, potentially leading to memory corruption if the\nhardware writes to it (the hardware continues to use the buffer from the\nrestore kernel).\n\nIt is also possible that the hardware \"forgets\" the address of the memory\nbuffer when resuming from \"deep\" suspend. Memory corruption may also occur\nin such a scenario.\n\nTo prevent the described memory corruption, disable HFI when preparing to\nsuspend or hibernate. Enable it when resuming.\n\nAdd syscore callbacks to handle the package of the boot CPU (packages of\nnon-boot CPUs are handled via CPU offline). Syscore ops always run on the\nboot CPU. Additionally, HFI only needs to be disabled during \"deep\" suspend\nand hibernation. Syscore ops only run in these cases.\n\n[ rjw: Comment adjustment, subject and changelog edits ]"
          },
          {
            "lang": "es",
            "value": "En el kernel de Linux, se resolvi\u00f3 la siguiente vulnerabilidad: t\u00e9rmica: intel: hfi: agregar devoluciones de llamada de syscore para PM en todo el sistema El kernel asigna un b\u00fafer de memoria y proporciona su ubicaci\u00f3n al hardware, que lo utiliza para actualizar la tabla HFI. Esta asignaci\u00f3n ocurre durante el arranque y permanece constante durante el tiempo de ejecuci\u00f3n. Al salir de la hibernaci\u00f3n, el kernel de restauraci\u00f3n asigna un segundo b\u00fafer de memoria y reprograma el hardware HFI con la nueva ubicaci\u00f3n como parte de un inicio normal. La ubicaci\u00f3n del segundo b\u00fafer de memoria puede diferir de la asignada por el n\u00facleo de la imagen. Cuando el kernel de restauraci\u00f3n transfiere el control al kernel de imagen, su b\u00fafer HFI deja de ser v\u00e1lido, lo que puede provocar da\u00f1os en la memoria si el hardware escribe en \u00e9l (el hardware contin\u00faa usando el b\u00fafer del kernel de restauraci\u00f3n). Tambi\u00e9n es posible que el hardware \"olvide\" la direcci\u00f3n del b\u00fafer de memoria al reanudar desde una suspensi\u00f3n \"profunda\". En tal escenario tambi\u00e9n puede ocurrir corrupci\u00f3n de memoria. Para evitar la corrupci\u00f3n de memoria descrita, desactive HFI cuando se prepare para suspender o hibernar. Habil\u00edtelo al reanudar. Agregue devoluciones de llamada de syscore para manejar el paquete de la CPU de arranque (los paquetes de CPU que no son de arranque se manejan a trav\u00e9s de la CPU sin conexi\u00f3n). Las operaciones de Syscore siempre se ejecutan en la CPU de arranque. Adem\u00e1s, HFI solo necesita desactivarse durante la suspensi\u00f3n e hibernaci\u00f3n \"profundas\". Las operaciones de Syscore solo se ejecutan en estos casos. [rjw: ajuste de comentarios, ediciones de asunto y registro de cambios]"
          }
        ],
        "id": "CVE-2024-26646",
        "lastModified": "2024-03-27T12:29:41.530",
        "metrics": {},
        "published": "2024-03-26T18:15:09.910",
        "references": [
          {
            "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
            "url": "https://git.kernel.org/stable/c/019ccc66d56a696a4dfee3bfa2f04d0a7c3d89ee"
          },
          {
            "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
            "url": "https://git.kernel.org/stable/c/28f010dc50df0f7987c04112114fcfa7e0803566"
          },
          {
            "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
            "url": "https://git.kernel.org/stable/c/97566d09fd02d2ab329774bb89a2cdf2267e86d9"
          },
          {
            "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
            "url": "https://git.kernel.org/stable/c/c9d6d63b6c03afaa6f185df249af693a7939577c"
          }
        ],
        "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
        "vulnStatus": "Awaiting Analysis"
      }
    }
  }
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.


Loading…

Loading…

Loading…

Sightings

Author Source Type Date

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.


Loading…

Detection rules are retrieved from Rulezet.

Loading…

Loading…