ghsa-w77r-vc72-rx49
Vulnerability from github
Published
2024-05-17 15:31
Modified
2024-05-17 15:31
Details

In the Linux kernel, the following vulnerability has been resolved:

x86/efistub: Call mixed mode boot services on the firmware's stack

Normally, the EFI stub calls into the EFI boot services using the stack that was live when the stub was entered. According to the UEFI spec, this stack needs to be at least 128k in size - this might seem large but all asynchronous processing and event handling in EFI runs from the same stack and so quite a lot of space may be used in practice.

In mixed mode, the situation is a bit different: the bootloader calls the 32-bit EFI stub entry point, which calls the decompressor's 32-bit entry point, where the boot stack is set up, using a fixed allocation of 16k. This stack is still in use when the EFI stub is started in 64-bit mode, and so all calls back into the EFI firmware will be using the decompressor's limited boot stack.

Due to the placement of the boot stack right after the boot heap, any stack overruns have gone unnoticed. However, commit

5c4feadb0011983b ("x86/decompressor: Move global symbol references to C code")

moved the definition of the boot heap into C code, and now the boot stack is placed right at the base of BSS, where any overruns will corrupt the end of the .data section.

While it would be possible to work around this by increasing the size of the boot stack, doing so would affect all x86 systems, and mixed mode systems are a tiny (and shrinking) fraction of the x86 installed base.

So instead, record the firmware stack pointer value when entering from the 32-bit firmware, and switch to this stack every time a EFI boot service call is made.

Show details on source website

To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2024-35803"
  ],
  "database_specific": {
    "cwe_ids": [],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-05-17T14:15:13Z",
    "severity": null
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nx86/efistub: Call mixed mode boot services on the firmware\u0027s stack\n\nNormally, the EFI stub calls into the EFI boot services using the stack\nthat was live when the stub was entered. According to the UEFI spec,\nthis stack needs to be at least 128k in size - this might seem large but\nall asynchronous processing and event handling in EFI runs from the same\nstack and so quite a lot of space may be used in practice.\n\nIn mixed mode, the situation is a bit different: the bootloader calls\nthe 32-bit EFI stub entry point, which calls the decompressor\u0027s 32-bit\nentry point, where the boot stack is set up, using a fixed allocation\nof 16k. This stack is still in use when the EFI stub is started in\n64-bit mode, and so all calls back into the EFI firmware will be using\nthe decompressor\u0027s limited boot stack.\n\nDue to the placement of the boot stack right after the boot heap, any\nstack overruns have gone unnoticed. However, commit\n\n  5c4feadb0011983b (\"x86/decompressor: Move global symbol references to C code\")\n\nmoved the definition of the boot heap into C code, and now the boot\nstack is placed right at the base of BSS, where any overruns will\ncorrupt the end of the .data section.\n\nWhile it would be possible to work around this by increasing the size of\nthe boot stack, doing so would affect all x86 systems, and mixed mode\nsystems are a tiny (and shrinking) fraction of the x86 installed base.\n\nSo instead, record the firmware stack pointer value when entering from\nthe 32-bit firmware, and switch to this stack every time a EFI boot\nservice call is made.",
  "id": "GHSA-w77r-vc72-rx49",
  "modified": "2024-05-17T15:31:09Z",
  "published": "2024-05-17T15:31:09Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35803"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/2149f8a56e2ed345c7a4d022a79f6b8fc53ae926"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/725351c036452b7db5771a7bed783564bc4b99cc"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/930775060ca348b8665f60eef14b204172d14f31"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/cefcd4fe2e3aaf792c14c9e56dab89e3d7a65d02"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/fba7ee7187581b5bc222003e73e2592b398bb06d"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}


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.