github - ghsa-g596-f5rr-4qjp

GHSA-G596-F5RR-4QJP

Vulnerability from github – Published: 2024-09-04 21:30 – Updated: 2024-10-09 15:32

Details

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

KEYS: trusted: dcp: fix leak of blob encryption key

Trusted keys unseal the key blob on load, but keep the sealed payload in the blob field so that every subsequent read (export) will simply convert this field to hex and send it to userspace.

With DCP-based trusted keys, we decrypt the blob encryption key (BEK) in the Kernel due hardware limitations and then decrypt the blob payload. BEK decryption is done in-place which means that the trusted key blob field is modified and it consequently holds the BEK in plain text. Every subsequent read of that key thus send the plain text BEK instead of the encrypted BEK to userspace.

This issue only occurs when importing a trusted DCP-based key and then exporting it again. This should rarely happen as the common use cases are to either create a new trusted key and export it, or import a key blob and then just use it without exporting it again.

Fix this by performing BEK decryption and encryption in a dedicated buffer. Further always wipe the plain text BEK buffer to prevent leaking the key via uninitialized memory.

Severity ?

5.5 (Medium)


                  
                    CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2024-45004"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-312"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-09-04T20:15:08Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nKEYS: trusted: dcp: fix leak of blob encryption key\n\nTrusted keys unseal the key blob on load, but keep the sealed payload in\nthe blob field so that every subsequent read (export) will simply\nconvert this field to hex and send it to userspace.\n\nWith DCP-based trusted keys, we decrypt the blob encryption key (BEK)\nin the Kernel due hardware limitations and then decrypt the blob payload.\nBEK decryption is done in-place which means that the trusted key blob\nfield is modified and it consequently holds the BEK in plain text.\nEvery subsequent read of that key thus send the plain text BEK instead\nof the encrypted BEK to userspace.\n\nThis issue only occurs when importing a trusted DCP-based key and\nthen exporting it again. This should rarely happen as the common use cases\nare to either create a new trusted key and export it, or import a key\nblob and then just use it without exporting it again.\n\nFix this by performing BEK decryption and encryption in a dedicated\nbuffer. Further always wipe the plain text BEK buffer to prevent leaking\nthe key via uninitialized memory.",
  "id": "GHSA-g596-f5rr-4qjp",
  "modified": "2024-10-09T15:32:18Z",
  "published": "2024-09-04T21:30:33Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-45004"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/0e28bf61a5f9ab30be3f3b4eafb8d097e39446bb"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/9e3b266afcfe4294e84496f50f006f029d3100db"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

CVE-2024-45004 (GCVE-0-2024-45004)

Vulnerability from cvelistv5 – Published: 2024-09-04 19:54 – Updated: 2025-05-04 09:30

Summary

In the Linux kernel, the following vulnerability has been resolved: KEYS: trusted: dcp: fix leak of blob encryption key Trusted keys unseal the key blob on load, but keep the sealed payload in the blob field so that every subsequent read (export) will simply convert this field to hex and send it to userspace. With DCP-based trusted keys, we decrypt the blob encryption key (BEK) in the Kernel due hardware limitations and then decrypt the blob payload. BEK decryption is done in-place which means that the trusted key blob field is modified and it consequently holds the BEK in plain text. Every subsequent read of that key thus send the plain text BEK instead of the encrypted BEK to userspace. This issue only occurs when importing a trusted DCP-based key and then exporting it again. This should rarely happen as the common use cases are to either create a new trusted key and export it, or import a key blob and then just use it without exporting it again. Fix this by performing BEK decryption and encryption in a dedicated buffer. Further always wipe the plain text BEK buffer to prevent leaking the key via uninitialized memory.

Severity ?

No CVSS data available.

Assigner

Linux

References

URL

Tags

	https://git.kernel.org/stable/c/9e3b266afcfe4294e…
	https://git.kernel.org/stable/c/0e28bf61a5f9ab30b…

Impacted products

Vendor

Product

Version

Linux

Affected: 2e8a0f40a39cc253002f21c54e1b5b995e5ec510 , < 9e3b266afcfe4294e84496f50f006f029d3100db (git)
Affected: 2e8a0f40a39cc253002f21c54e1b5b995e5ec510 , < 0e28bf61a5f9ab30be3f3b4eafb8d097e39446bb (git)

Linux

Affected: 6.10
Unaffected: 0 , < 6.10 (semver)
Unaffected: 6.10.7 , ≤ 6.10.* (semver)
Unaffected: 6.11 , ≤ * (original_commit_for_fix)

Show details on NVD website

JSON

To clipboard

{
  "containers": {
    "adp": [
      {
        "metrics": [
          {
            "other": {
              "content": {
                "id": "CVE-2024-45004",
                "options": [
                  {
                    "Exploitation": "none"
                  },
                  {
                    "Automatable": "no"
                  },
                  {
                    "Technical Impact": "partial"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2024-09-04T20:18:21.525724Z",
                "version": "2.0.3"
              },
              "type": "ssvc"
            }
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2024-09-04T20:18:44.171Z",
          "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
          "shortName": "CISA-ADP"
        },
        "title": "CISA ADP Vulnrichment"
      }
    ],
    "cna": {
      "affected": [
        {
          "defaultStatus": "unaffected",
          "product": "Linux",
          "programFiles": [
            "security/keys/trusted-keys/trusted_dcp.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "lessThan": "9e3b266afcfe4294e84496f50f006f029d3100db",
              "status": "affected",
              "version": "2e8a0f40a39cc253002f21c54e1b5b995e5ec510",
              "versionType": "git"
            },
            {
              "lessThan": "0e28bf61a5f9ab30be3f3b4eafb8d097e39446bb",
              "status": "affected",
              "version": "2e8a0f40a39cc253002f21c54e1b5b995e5ec510",
              "versionType": "git"
            }
          ]
        },
        {
          "defaultStatus": "affected",
          "product": "Linux",
          "programFiles": [
            "security/keys/trusted-keys/trusted_dcp.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "status": "affected",
              "version": "6.10"
            },
            {
              "lessThan": "6.10",
              "status": "unaffected",
              "version": "0",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.10.*",
              "status": "unaffected",
              "version": "6.10.7",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "*",
              "status": "unaffected",
              "version": "6.11",
              "versionType": "original_commit_for_fix"
            }
          ]
        }
      ],
      "cpeApplicability": [
        {
          "nodes": [
            {
              "cpeMatch": [
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.10.7",
                  "versionStartIncluding": "6.10",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.11",
                  "versionStartIncluding": "6.10",
                  "vulnerable": true
                }
              ],
              "negate": false,
              "operator": "OR"
            }
          ]
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nKEYS: trusted: dcp: fix leak of blob encryption key\n\nTrusted keys unseal the key blob on load, but keep the sealed payload in\nthe blob field so that every subsequent read (export) will simply\nconvert this field to hex and send it to userspace.\n\nWith DCP-based trusted keys, we decrypt the blob encryption key (BEK)\nin the Kernel due hardware limitations and then decrypt the blob payload.\nBEK decryption is done in-place which means that the trusted key blob\nfield is modified and it consequently holds the BEK in plain text.\nEvery subsequent read of that key thus send the plain text BEK instead\nof the encrypted BEK to userspace.\n\nThis issue only occurs when importing a trusted DCP-based key and\nthen exporting it again. This should rarely happen as the common use cases\nare to either create a new trusted key and export it, or import a key\nblob and then just use it without exporting it again.\n\nFix this by performing BEK decryption and encryption in a dedicated\nbuffer. Further always wipe the plain text BEK buffer to prevent leaking\nthe key via uninitialized memory."
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2025-05-04T09:30:50.442Z",
        "orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
        "shortName": "Linux"
      },
      "references": [
        {
          "url": "https://git.kernel.org/stable/c/9e3b266afcfe4294e84496f50f006f029d3100db"
        },
        {
          "url": "https://git.kernel.org/stable/c/0e28bf61a5f9ab30be3f3b4eafb8d097e39446bb"
        }
      ],
      "title": "KEYS: trusted: dcp: fix leak of blob encryption key",
      "x_generator": {
        "engine": "bippy-1.2.0"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
    "assignerShortName": "Linux",
    "cveId": "CVE-2024-45004",
    "datePublished": "2024-09-04T19:54:46.952Z",
    "dateReserved": "2024-08-21T05:34:56.678Z",
    "dateUpdated": "2025-05-04T09:30:50.442Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.1"
}

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.

Detection rules are retrieved from Rulezet.

Action not permitted

GHSA-G596-F5RR-4QJP

CVE-2024-45004 (GCVE-0-2024-45004)

Tags

Sightings

Nomenclature