GSD-2024-26584

Vulnerability from gsd - Updated: 2024-02-20 06:02
Details
In the Linux kernel, the following vulnerability has been resolved: net: tls: handle backlogging of crypto requests Since we're setting the CRYPTO_TFM_REQ_MAY_BACKLOG flag on our requests to the crypto API, crypto_aead_{encrypt,decrypt} can return -EBUSY instead of -EINPROGRESS in valid situations. For example, when the cryptd queue for AESNI is full (easy to trigger with an artificially low cryptd.cryptd_max_cpu_qlen), requests will be enqueued to the backlog but still processed. In that case, the async callback will also be called twice: first with err == -EINPROGRESS, which it seems we can just ignore, then with err == 0. Compared to Sabrina's original patch this version uses the new tls_*crypt_async_wait() helpers and converts the EBUSY to EINPROGRESS to avoid having to modify all the error handling paths. The handling is identical.
Aliases
To clipboard 

{
  "gsd": {
    "metadata": {
      "exploitCode": "unknown",
      "remediation": "unknown",
      "reportConfidence": "confirmed",
      "type": "vulnerability"
    },
    "osvSchema": {
      "aliases": [
        "CVE-2024-26584"
      ],
      "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: tls: handle backlogging of crypto requests\n\nSince we\u0027re setting the CRYPTO_TFM_REQ_MAY_BACKLOG flag on our\nrequests to the crypto API, crypto_aead_{encrypt,decrypt} can return\n -EBUSY instead of -EINPROGRESS in valid situations. For example, when\nthe cryptd queue for AESNI is full (easy to trigger with an\nartificially low cryptd.cryptd_max_cpu_qlen), requests will be enqueued\nto the backlog but still processed. In that case, the async callback\nwill also be called twice: first with err == -EINPROGRESS, which it\nseems we can just ignore, then with err == 0.\n\nCompared to Sabrina\u0027s original patch this version uses the new\ntls_*crypt_async_wait() helpers and converts the EBUSY to\nEINPROGRESS to avoid having to modify all the error handling\npaths. The handling is identical.",
      "id": "GSD-2024-26584",
      "modified": "2024-02-20T06:02:29.096869Z",
      "schema_version": "1.4.0"
    }
  },
  "namespaces": {
    "cve.org": {
      "CVE_data_meta": {
        "ASSIGNER": "cve@kernel.org",
        "ID": "CVE-2024-26584",
        "STATE": "PUBLIC"
      },
      "affects": {
        "vendor": {
          "vendor_data": [
            {
              "product": {
                "product_data": [
                  {
                    "product_name": "Linux",
                    "version": {
                      "version_data": [
                        {
                          "version_affected": "\u003c",
                          "version_name": "a54667f6728c",
                          "version_value": "cd1bbca03f3c"
                        },
                        {
                          "version_value": "not down converted",
                          "x_cve_json_5_version_data": {
                            "defaultStatus": "affected",
                            "versions": [
                              {
                                "status": "affected",
                                "version": "4.16"
                              },
                              {
                                "lessThan": "4.16",
                                "status": "unaffected",
                                "version": "0",
                                "versionType": "custom"
                              },
                              {
                                "lessThanOrEqual": "6.1.*",
                                "status": "unaffected",
                                "version": "6.1.84",
                                "versionType": "custom"
                              },
                              {
                                "lessThanOrEqual": "6.6.*",
                                "status": "unaffected",
                                "version": "6.6.18",
                                "versionType": "custom"
                              },
                              {
                                "lessThanOrEqual": "6.7.*",
                                "status": "unaffected",
                                "version": "6.7.6",
                                "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\nnet: tls: handle backlogging of crypto requests\n\nSince we\u0027re setting the CRYPTO_TFM_REQ_MAY_BACKLOG flag on our\nrequests to the crypto API, crypto_aead_{encrypt,decrypt} can return\n -EBUSY instead of -EINPROGRESS in valid situations. For example, when\nthe cryptd queue for AESNI is full (easy to trigger with an\nartificially low cryptd.cryptd_max_cpu_qlen), requests will be enqueued\nto the backlog but still processed. In that case, the async callback\nwill also be called twice: first with err == -EINPROGRESS, which it\nseems we can just ignore, then with err == 0.\n\nCompared to Sabrina\u0027s original patch this version uses the new\ntls_*crypt_async_wait() helpers and converts the EBUSY to\nEINPROGRESS to avoid having to modify all the error handling\npaths. The handling is identical."
          }
        ]
      },
      "generator": {
        "engine": "bippy-5f0117140d9a"
      },
      "problemtype": {
        "problemtype_data": [
          {
            "description": [
              {
                "lang": "eng",
                "value": "n/a"
              }
            ]
          }
        ]
      },
      "references": {
        "reference_data": [
          {
            "name": "https://git.kernel.org/stable/c/cd1bbca03f3c1d845ce274c0d0a66de8e5929f72",
            "refsource": "MISC",
            "url": "https://git.kernel.org/stable/c/cd1bbca03f3c1d845ce274c0d0a66de8e5929f72"
          },
          {
            "name": "https://git.kernel.org/stable/c/13eca403876bbea3716e82cdfe6f1e6febb38754",
            "refsource": "MISC",
            "url": "https://git.kernel.org/stable/c/13eca403876bbea3716e82cdfe6f1e6febb38754"
          },
          {
            "name": "https://git.kernel.org/stable/c/ab6397f072e5097f267abf5cb08a8004e6b17694",
            "refsource": "MISC",
            "url": "https://git.kernel.org/stable/c/ab6397f072e5097f267abf5cb08a8004e6b17694"
          },
          {
            "name": "https://git.kernel.org/stable/c/8590541473188741055d27b955db0777569438e3",
            "refsource": "MISC",
            "url": "https://git.kernel.org/stable/c/8590541473188741055d27b955db0777569438e3"
          }
        ]
      }
    },
    "nvd.nist.gov": {
      "cve": {
        "descriptions": [
          {
            "lang": "en",
            "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: tls: handle backlogging of crypto requests\n\nSince we\u0027re setting the CRYPTO_TFM_REQ_MAY_BACKLOG flag on our\nrequests to the crypto API, crypto_aead_{encrypt,decrypt} can return\n -EBUSY instead of -EINPROGRESS in valid situations. For example, when\nthe cryptd queue for AESNI is full (easy to trigger with an\nartificially low cryptd.cryptd_max_cpu_qlen), requests will be enqueued\nto the backlog but still processed. In that case, the async callback\nwill also be called twice: first with err == -EINPROGRESS, which it\nseems we can just ignore, then with err == 0.\n\nCompared to Sabrina\u0027s original patch this version uses the new\ntls_*crypt_async_wait() helpers and converts the EBUSY to\nEINPROGRESS to avoid having to modify all the error handling\npaths. The handling is identical."
          },
          {
            "lang": "es",
            "value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: tls: manejar el retraso de solicitudes criptogr\u00e1ficas Dado que estamos configurando el indicador CRYPTO_TFM_REQ_MAY_BACKLOG en nuestras solicitudes a la API criptogr\u00e1fica, crypto_aead_{encrypt,decrypt} puede devolver -EBUSY en lugar de - EINPROGRESS en situaciones v\u00e1lidas. Por ejemplo, cuando la cola cryptd para AESNI est\u00e1 llena (f\u00e1cil de activar con un cryptd.cryptd_max_cpu_qlen artificialmente bajo), las solicitudes se pondr\u00e1n en cola en el trabajo pendiente, pero a\u00fan as\u00ed se procesar\u00e1n. En ese caso, la devoluci\u00f3n de llamada as\u00edncrona tambi\u00e9n se llamar\u00e1 dos veces: primero con err == -EINPROGRESS, que parece que podemos ignorar, luego con err == 0. En comparaci\u00f3n con el parche original de Sabrina, esta versi\u00f3n usa el nuevo tls_*crypt_async_wait( ) ayuda y convierte EBUSY a EINPROGRESS para evitar tener que modificar todas las rutas de manejo de errores. El manejo es id\u00e9ntico."
          }
        ],
        "id": "CVE-2024-26584",
        "lastModified": "2024-04-03T14:15:15.613",
        "metrics": {},
        "published": "2024-02-21T15:15:09.420",
        "references": [
          {
            "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
            "url": "https://git.kernel.org/stable/c/13eca403876bbea3716e82cdfe6f1e6febb38754"
          },
          {
            "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
            "url": "https://git.kernel.org/stable/c/8590541473188741055d27b955db0777569438e3"
          },
          {
            "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
            "url": "https://git.kernel.org/stable/c/ab6397f072e5097f267abf5cb08a8004e6b17694"
          },
          {
            "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
            "url": "https://git.kernel.org/stable/c/cd1bbca03f3c1d845ce274c0d0a66de8e5929f72"
          }
        ],
        "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
        "vulnStatus": "Awaiting Analysis"
      }
    }
  }
}


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 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.