CVE-2021-32629
Vulnerability from cvelistv5
Published
2021-05-24 15:35
Modified
2024-08-03 23:25
Severity ?
7.2 (High) - CVSS:3.1/AV:L/AC:H/PR:L/UI:R/S:C/C:H/I:H/A:N
Summary
Cranelift is an open-source code generator maintained by Bytecode Alliance. It translates a target-independent intermediate representation into executable machine code. There is a bug in 0.73 of the Cranelift x64 backend that can create a scenario that could result in a potential sandbox escape in a Wasm program. This bug was introduced in the new backend on 2020-09-08 and first included in a release on 2020-09-30, but the new backend was not the default prior to 0.73. The recently-released version 0.73 with default settings, and prior versions with an explicit build flag to select the new backend, are vulnerable. The bug in question performs a sign-extend instead of a zero-extend on a value loaded from the stack, under a specific set of circumstances. If those circumstances occur, the bug could allow access to memory addresses upto 2GiB before the start of the Wasm program heap. If the heap bound is larger than 2GiB, then it would be possible to read memory from a computable range dependent on the size of the heaps bound. The impact of this bug is highly dependent on heap implementation, specifically: * if the heap has bounds checks, and * does not rely exclusively on guard pages, and * the heap bound is 2GiB or smaller * then this bug cannot be used to reach memory from another Wasm program heap. The impact of the vulnerability is mitigated if there is no memory mapped in the range accessible using this bug, for example, if there is a 2 GiB guard region before the Wasm program heap. The bug in question performs a sign-extend instead of a zero-extend on a value loaded from the stack, when the register allocator reloads a spilled integer value narrower than 64 bits. This interacts poorly with another optimization: the instruction selector elides a 32-to-64-bit zero-extend operator when we know that an instruction producing a 32-bit value actually zeros the upper 32 bits of its destination register. Hence, we rely on these zeroed bits, but the type of the value is still i32, and the spill/reload reconstitutes those bits as the sign extension of the i32’s MSB. The issue would thus occur when: * An i32 value in a Wasm program is greater than or equal to 0x8000_0000; * The value is spilled and reloaded by the register allocator due to high register pressure in the program between the value’s definition and its use; * The value is produced by an instruction that we know to be “special” in that it zeroes the upper 32 bits of its destination: add, sub, mul, and, or; * The value is then zero-extended to 64 bits in the Wasm program; * The resulting 64-bit value is used. Under these circumstances there is a potential sandbox escape when the i32 value is a pointer. The usual code emitted for heap accesses zero-extends the Wasm heap address, adds it to a 64-bit heap base, and accesses the resulting address. If the zero-extend becomes a sign-extend, the program could reach backward and access memory up to 2GiB before the start of its heap. In addition to assessing the nature of the code generation bug in Cranelift, we have also determined that under specific circumstances, both Lucet and Wasmtime using this version of Cranelift may be exploitable. See referenced GitHub Advisory for more details.
References
security-advisories@github.comhttps://crates.io/crates/cranelift-codegenProduct, Third Party Advisory
security-advisories@github.comhttps://github.com/bytecodealliance/wasmtime/commit/95559c01aaa7c061088a433040f31e8291fb09d0Patch, Third Party Advisory
security-advisories@github.comhttps://github.com/bytecodealliance/wasmtime/security/advisories/GHSA-hpqh-2wqx-7qp5Exploit, Third Party Advisory
security-advisories@github.comhttps://www.fastly.com/security-advisories/memory-access-due-to-code-generation-flaw-in-cranelift-moduleThird Party Advisory
af854a3a-2127-422b-91ae-364da2661108https://crates.io/crates/cranelift-codegenProduct, Third Party Advisory
af854a3a-2127-422b-91ae-364da2661108https://github.com/bytecodealliance/wasmtime/commit/95559c01aaa7c061088a433040f31e8291fb09d0Patch, Third Party Advisory
af854a3a-2127-422b-91ae-364da2661108https://github.com/bytecodealliance/wasmtime/security/advisories/GHSA-hpqh-2wqx-7qp5Exploit, Third Party Advisory
af854a3a-2127-422b-91ae-364da2661108https://www.fastly.com/security-advisories/memory-access-due-to-code-generation-flaw-in-cranelift-moduleThird Party Advisory
Impacted products
Vendor Product Version
bytecodealliance wasmtime Version: <= 0.73.0
 Create a notification for this product.
Show details on NVD website

To clipboard 

{
  "containers": {
    "adp": [
      {
        "providerMetadata": {
          "dateUpdated": "2024-08-03T23:25:30.928Z",
          "orgId": "af854a3a-2127-422b-91ae-364da2661108",
          "shortName": "CVE"
        },
        "references": [
          {
            "tags": [
              "x_refsource_CONFIRM",
              "x_transferred"
            ],
            "url": "https://github.com/bytecodealliance/wasmtime/security/advisories/GHSA-hpqh-2wqx-7qp5"
          },
          {
            "tags": [
              "x_refsource_MISC",
              "x_transferred"
            ],
            "url": "https://github.com/bytecodealliance/wasmtime/commit/95559c01aaa7c061088a433040f31e8291fb09d0"
          },
          {
            "tags": [
              "x_refsource_MISC",
              "x_transferred"
            ],
            "url": "https://crates.io/crates/cranelift-codegen"
          },
          {
            "tags": [
              "x_refsource_MISC",
              "x_transferred"
            ],
            "url": "https://www.fastly.com/security-advisories/memory-access-due-to-code-generation-flaw-in-cranelift-module"
          }
        ],
        "title": "CVE Program Container"
      }
    ],
    "cna": {
      "affected": [
        {
          "product": "wasmtime",
          "vendor": "bytecodealliance",
          "versions": [
            {
              "status": "affected",
              "version": "\u003c= 0.73.0"
            }
          ]
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "Cranelift is an open-source code generator maintained by Bytecode Alliance. It translates a target-independent intermediate representation into executable machine code. There is a bug in 0.73 of the Cranelift x64 backend that can create a scenario that could result in a potential sandbox escape in a Wasm program. This bug was introduced in the new backend on 2020-09-08 and first included in a release on 2020-09-30, but the new backend was not the default prior to 0.73. The recently-released version 0.73 with default settings, and prior versions with an explicit build flag to select the new backend, are vulnerable. The bug in question performs a sign-extend instead of a zero-extend on a value loaded from the stack, under a specific set of circumstances. If those circumstances occur, the bug could allow access to memory addresses upto 2GiB before the start of the Wasm program heap. If the heap bound is larger than 2GiB, then it would be possible to read memory from a computable range dependent on the size of the heaps bound. The impact of this bug is highly dependent on heap implementation, specifically: * if the heap has bounds checks, and * does not rely exclusively on guard pages, and * the heap bound is 2GiB or smaller * then this bug cannot be used to reach memory from another Wasm program heap. The impact of the vulnerability is mitigated if there is no memory mapped in the range accessible using this bug, for example, if there is a 2 GiB guard region before the Wasm program heap. The bug in question performs a sign-extend instead of a zero-extend on a value loaded from the stack, when the register allocator reloads a spilled integer value narrower than 64 bits. This interacts poorly with another optimization: the instruction selector elides a 32-to-64-bit zero-extend operator when we know that an instruction producing a 32-bit value actually zeros the upper 32 bits of its destination register. Hence, we rely on these zeroed bits, but the type of the value is still i32, and the spill/reload reconstitutes those bits as the sign extension of the i32\u2019s MSB. The issue would thus occur when: * An i32 value in a Wasm program is greater than or equal to 0x8000_0000; * The value is spilled and reloaded by the register allocator due to high register pressure in the program between the value\u2019s definition and its use; * The value is produced by an instruction that we know to be \u201cspecial\u201d in that it zeroes the upper 32 bits of its destination: add, sub, mul, and, or; * The value is then zero-extended to 64 bits in the Wasm program; * The resulting 64-bit value is used. Under these circumstances there is a potential sandbox escape when the i32 value is a pointer. The usual code emitted for heap accesses zero-extends the Wasm heap address, adds it to a 64-bit heap base, and accesses the resulting address. If the zero-extend becomes a sign-extend, the program could reach backward and access memory up to 2GiB before the start of its heap. In addition to assessing the nature of the code generation bug in Cranelift, we have also determined that under specific circumstances, both Lucet and Wasmtime using this version of Cranelift may be exploitable. See referenced GitHub Advisory for more details."
        }
      ],
      "metrics": [
        {
          "cvssV3_1": {
            "attackComplexity": "HIGH",
            "attackVector": "LOCAL",
            "availabilityImpact": "NONE",
            "baseScore": 7.2,
            "baseSeverity": "HIGH",
            "confidentialityImpact": "HIGH",
            "integrityImpact": "HIGH",
            "privilegesRequired": "LOW",
            "scope": "CHANGED",
            "userInteraction": "REQUIRED",
            "vectorString": "CVSS:3.1/AV:L/AC:H/PR:L/UI:R/S:C/C:H/I:H/A:N",
            "version": "3.1"
          }
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-788",
              "description": "CWE-788 Access of Memory Location After End of Buffer",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2021-05-24T15:35:11",
        "orgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
        "shortName": "GitHub_M"
      },
      "references": [
        {
          "tags": [
            "x_refsource_CONFIRM"
          ],
          "url": "https://github.com/bytecodealliance/wasmtime/security/advisories/GHSA-hpqh-2wqx-7qp5"
        },
        {
          "tags": [
            "x_refsource_MISC"
          ],
          "url": "https://github.com/bytecodealliance/wasmtime/commit/95559c01aaa7c061088a433040f31e8291fb09d0"
        },
        {
          "tags": [
            "x_refsource_MISC"
          ],
          "url": "https://crates.io/crates/cranelift-codegen"
        },
        {
          "tags": [
            "x_refsource_MISC"
          ],
          "url": "https://www.fastly.com/security-advisories/memory-access-due-to-code-generation-flaw-in-cranelift-module"
        }
      ],
      "source": {
        "advisory": "GHSA-hpqh-2wqx-7qp5",
        "discovery": "UNKNOWN"
      },
      "title": "Memory access due to code generation flaw in Cranelift module",
      "x_legacyV4Record": {
        "CVE_data_meta": {
          "ASSIGNER": "security-advisories@github.com",
          "ID": "CVE-2021-32629",
          "STATE": "PUBLIC",
          "TITLE": "Memory access due to code generation flaw in Cranelift module"
        },
        "affects": {
          "vendor": {
            "vendor_data": [
              {
                "product": {
                  "product_data": [
                    {
                      "product_name": "wasmtime",
                      "version": {
                        "version_data": [
                          {
                            "version_value": "\u003c= 0.73.0"
                          }
                        ]
                      }
                    }
                  ]
                },
                "vendor_name": "bytecodealliance"
              }
            ]
          }
        },
        "data_format": "MITRE",
        "data_type": "CVE",
        "data_version": "4.0",
        "description": {
          "description_data": [
            {
              "lang": "eng",
              "value": "Cranelift is an open-source code generator maintained by Bytecode Alliance. It translates a target-independent intermediate representation into executable machine code. There is a bug in 0.73 of the Cranelift x64 backend that can create a scenario that could result in a potential sandbox escape in a Wasm program. This bug was introduced in the new backend on 2020-09-08 and first included in a release on 2020-09-30, but the new backend was not the default prior to 0.73. The recently-released version 0.73 with default settings, and prior versions with an explicit build flag to select the new backend, are vulnerable. The bug in question performs a sign-extend instead of a zero-extend on a value loaded from the stack, under a specific set of circumstances. If those circumstances occur, the bug could allow access to memory addresses upto 2GiB before the start of the Wasm program heap. If the heap bound is larger than 2GiB, then it would be possible to read memory from a computable range dependent on the size of the heaps bound. The impact of this bug is highly dependent on heap implementation, specifically: * if the heap has bounds checks, and * does not rely exclusively on guard pages, and * the heap bound is 2GiB or smaller * then this bug cannot be used to reach memory from another Wasm program heap. The impact of the vulnerability is mitigated if there is no memory mapped in the range accessible using this bug, for example, if there is a 2 GiB guard region before the Wasm program heap. The bug in question performs a sign-extend instead of a zero-extend on a value loaded from the stack, when the register allocator reloads a spilled integer value narrower than 64 bits. This interacts poorly with another optimization: the instruction selector elides a 32-to-64-bit zero-extend operator when we know that an instruction producing a 32-bit value actually zeros the upper 32 bits of its destination register. Hence, we rely on these zeroed bits, but the type of the value is still i32, and the spill/reload reconstitutes those bits as the sign extension of the i32\u2019s MSB. The issue would thus occur when: * An i32 value in a Wasm program is greater than or equal to 0x8000_0000; * The value is spilled and reloaded by the register allocator due to high register pressure in the program between the value\u2019s definition and its use; * The value is produced by an instruction that we know to be \u201cspecial\u201d in that it zeroes the upper 32 bits of its destination: add, sub, mul, and, or; * The value is then zero-extended to 64 bits in the Wasm program; * The resulting 64-bit value is used. Under these circumstances there is a potential sandbox escape when the i32 value is a pointer. The usual code emitted for heap accesses zero-extends the Wasm heap address, adds it to a 64-bit heap base, and accesses the resulting address. If the zero-extend becomes a sign-extend, the program could reach backward and access memory up to 2GiB before the start of its heap. In addition to assessing the nature of the code generation bug in Cranelift, we have also determined that under specific circumstances, both Lucet and Wasmtime using this version of Cranelift may be exploitable. See referenced GitHub Advisory for more details."
            }
          ]
        },
        "impact": {
          "cvss": {
            "attackComplexity": "HIGH",
            "attackVector": "LOCAL",
            "availabilityImpact": "NONE",
            "baseScore": 7.2,
            "baseSeverity": "HIGH",
            "confidentialityImpact": "HIGH",
            "integrityImpact": "HIGH",
            "privilegesRequired": "LOW",
            "scope": "CHANGED",
            "userInteraction": "REQUIRED",
            "vectorString": "CVSS:3.1/AV:L/AC:H/PR:L/UI:R/S:C/C:H/I:H/A:N",
            "version": "3.1"
          }
        },
        "problemtype": {
          "problemtype_data": [
            {
              "description": [
                {
                  "lang": "eng",
                  "value": "CWE-788 Access of Memory Location After End of Buffer"
                }
              ]
            }
          ]
        },
        "references": {
          "reference_data": [
            {
              "name": "https://github.com/bytecodealliance/wasmtime/security/advisories/GHSA-hpqh-2wqx-7qp5",
              "refsource": "CONFIRM",
              "url": "https://github.com/bytecodealliance/wasmtime/security/advisories/GHSA-hpqh-2wqx-7qp5"
            },
            {
              "name": "https://github.com/bytecodealliance/wasmtime/commit/95559c01aaa7c061088a433040f31e8291fb09d0",
              "refsource": "MISC",
              "url": "https://github.com/bytecodealliance/wasmtime/commit/95559c01aaa7c061088a433040f31e8291fb09d0"
            },
            {
              "name": "https://crates.io/crates/cranelift-codegen",
              "refsource": "MISC",
              "url": "https://crates.io/crates/cranelift-codegen"
            },
            {
              "name": "https://www.fastly.com/security-advisories/memory-access-due-to-code-generation-flaw-in-cranelift-module",
              "refsource": "MISC",
              "url": "https://www.fastly.com/security-advisories/memory-access-due-to-code-generation-flaw-in-cranelift-module"
            }
          ]
        },
        "source": {
          "advisory": "GHSA-hpqh-2wqx-7qp5",
          "discovery": "UNKNOWN"
        }
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
    "assignerShortName": "GitHub_M",
    "cveId": "CVE-2021-32629",
    "datePublished": "2021-05-24T15:35:11",
    "dateReserved": "2021-05-12T00:00:00",
    "dateUpdated": "2024-08-03T23:25:30.928Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.1",
  "vulnerability-lookup:meta": {
    "nvd": "{\"cve\":{\"id\":\"CVE-2021-32629\",\"sourceIdentifier\":\"security-advisories@github.com\",\"published\":\"2021-05-24T16:15:08.087\",\"lastModified\":\"2024-11-21T06:07:24.877\",\"vulnStatus\":\"Modified\",\"cveTags\":[],\"descriptions\":[{\"lang\":\"en\",\"value\":\"Cranelift is an open-source code generator maintained by Bytecode Alliance. It translates a target-independent intermediate representation into executable machine code. There is a bug in 0.73 of the Cranelift x64 backend that can create a scenario that could result in a potential sandbox escape in a Wasm program. This bug was introduced in the new backend on 2020-09-08 and first included in a release on 2020-09-30, but the new backend was not the default prior to 0.73. The recently-released version 0.73 with default settings, and prior versions with an explicit build flag to select the new backend, are vulnerable. The bug in question performs a sign-extend instead of a zero-extend on a value loaded from the stack, under a specific set of circumstances. If those circumstances occur, the bug could allow access to memory addresses upto 2GiB before the start of the Wasm program heap. If the heap bound is larger than 2GiB, then it would be possible to read memory from a computable range dependent on the size of the heaps bound. The impact of this bug is highly dependent on heap implementation, specifically: * if the heap has bounds checks, and * does not rely exclusively on guard pages, and * the heap bound is 2GiB or smaller * then this bug cannot be used to reach memory from another Wasm program heap. The impact of the vulnerability is mitigated if there is no memory mapped in the range accessible using this bug, for example, if there is a 2 GiB guard region before the Wasm program heap. The bug in question performs a sign-extend instead of a zero-extend on a value loaded from the stack, when the register allocator reloads a spilled integer value narrower than 64 bits. This interacts poorly with another optimization: the instruction selector elides a 32-to-64-bit zero-extend operator when we know that an instruction producing a 32-bit value actually zeros the upper 32 bits of its destination register. Hence, we rely on these zeroed bits, but the type of the value is still i32, and the spill/reload reconstitutes those bits as the sign extension of the i32\u2019s MSB. The issue would thus occur when: * An i32 value in a Wasm program is greater than or equal to 0x8000_0000; * The value is spilled and reloaded by the register allocator due to high register pressure in the program between the value\u2019s definition and its use; * The value is produced by an instruction that we know to be \u201cspecial\u201d in that it zeroes the upper 32 bits of its destination: add, sub, mul, and, or; * The value is then zero-extended to 64 bits in the Wasm program; * The resulting 64-bit value is used. Under these circumstances there is a potential sandbox escape when the i32 value is a pointer. The usual code emitted for heap accesses zero-extends the Wasm heap address, adds it to a 64-bit heap base, and accesses the resulting address. If the zero-extend becomes a sign-extend, the program could reach backward and access memory up to 2GiB before the start of its heap. In addition to assessing the nature of the code generation bug in Cranelift, we have also determined that under specific circumstances, both Lucet and Wasmtime using this version of Cranelift may be exploitable. See referenced GitHub Advisory for more details.\"},{\"lang\":\"es\",\"value\":\"Cranelift es un generador de c\u00f3digo abierto mantenido por Bytecode Alliance. Traduce una representaci\u00f3n intermedia independiente del objetivo en c\u00f3digo m\u00e1quina ejecutable. Hay un error en la versi\u00f3n 0.73 del backend de Cranelift x64 que puede crear un escenario que podr\u00eda dar lugar a una potencial fuga de la caja de arena en un programa Wasm. Este error se introdujo en el nuevo backend el 2020-09-08 y se incluy\u00f3 por primera vez en una versi\u00f3n el 2020-09-30, pero el nuevo backend no era el predeterminado antes de 0.73. La versi\u00f3n 0.73 recientemente lanzada con la configuraci\u00f3n por defecto, y las versiones anteriores con una bandera de construcci\u00f3n expl\u00edcita para seleccionar el nuevo backend, son vulnerables. El fallo en cuesti\u00f3n realiza un signo-extensi\u00f3n en lugar de un cero-extensi\u00f3n en un valor cargado desde la pila, bajo un conjunto espec\u00edfico de circunstancias. Si se dan esas circunstancias, el fallo podr\u00eda permitir el acceso a direcciones de memoria de hasta 2GiB antes del inicio de la pila del programa Wasm. Si el l\u00edmite del heap es mayor que 2GiB, entonces ser\u00eda posible leer memoria de un rango computable dependiente del tama\u00f1o del l\u00edmite del heaps. El impacto de este error depende en gran medida de la implementaci\u00f3n de la pila, espec\u00edficamente: * si el heap tiene comprobaciones de l\u00edmites, y * no depende exclusivamente de p\u00e1ginas de guardia, y * el l\u00edmite del heap es de 2GiB o menor * entonces este fallo no puede ser usado para alcanzar memoria desde otro heap del programa Wasm. El impacto de la vulnerabilidad se mitiga si no hay memoria mapeada en el rango accesible usando este bug, por ejemplo, si hay una regi\u00f3n de guardia de 2 GiB antes del heap del programa Wasm. El fallo en cuesti\u00f3n realiza un signo-extensi\u00f3n en lugar de un cero-extensi\u00f3n en un valor cargado desde la pila, cuando el asignador de registros recarga un valor entero derramado m\u00e1s estrecho que 64 bits. Esto interact\u00faa mal con otra optimizaci\u00f3n: el selector de instrucciones elude un operador de extensi\u00f3n a cero de 32 a 64 bits cuando sabemos que una instrucci\u00f3n que produce un valor de 32 bits realmente pone a cero los 32 bits superiores de su registro de destino. Por lo tanto, nos basamos en estos bits a cero, pero el tipo del valor sigue siendo i32, y el derrame/recarga reconstituye esos bits como la extensi\u00f3n del signo del MSB de i32. Por lo tanto, el problema ocurrir\u00eda cuando: * Un valor i32 en un programa Wasm es mayor o igual a 0x8000_0000; * El valor es derramado y recargado por el asignador de registros debido a la alta presi\u00f3n de registros en el programa entre la definici\u00f3n del valor y su uso; * El valor es producido por una instrucci\u00f3n que sabemos que es \\\"especial\\\" en el sentido de que pone a cero los 32 bits superiores de su destino: add, sub, mul, and, or; * El valor es entonces extendido a cero a 64 bits en el programa Wasm; * El valor de 64 bits resultante es utilizado. Bajo estas circunstancias hay un potencial escape de la caja de arena cuando el valor i32 es un puntero. El c\u00f3digo habitual emitido para los accesos al heap extiende a cero la direcci\u00f3n del heap de Wasm, la a\u00f1ade a una base del heap de 64 bits, y accede a la direcci\u00f3n resultante. Si el zero-extend se convierte en un sign-extend, el programa podr\u00eda llegar hacia atr\u00e1s y acceder a la memoria hasta 2GiB antes del inicio de su heap. Adem\u00e1s de evaluar la naturaleza del fallo de generaci\u00f3n de c\u00f3digo en Cranelift, tambi\u00e9n hemos determinado que, en circunstancias espec\u00edficas, tanto Lucet como Wasmtime que utilizan esta versi\u00f3n de Cranelift pueden ser explotables. Consulte el aviso de GitHub mencionado para obtener m\u00e1s detalles\"}],\"metrics\":{\"cvssMetricV31\":[{\"source\":\"security-advisories@github.com\",\"type\":\"Secondary\",\"cvssData\":{\"version\":\"3.1\",\"vectorString\":\"CVSS:3.1/AV:L/AC:H/PR:L/UI:R/S:C/C:H/I:H/A:N\",\"baseScore\":7.2,\"baseSeverity\":\"HIGH\",\"attackVector\":\"LOCAL\",\"attackComplexity\":\"HIGH\",\"privilegesRequired\":\"LOW\",\"userInteraction\":\"REQUIRED\",\"scope\":\"CHANGED\",\"confidentialityImpact\":\"HIGH\",\"integrityImpact\":\"HIGH\",\"availabilityImpact\":\"NONE\"},\"exploitabilityScore\":0.8,\"impactScore\":5.8},{\"source\":\"nvd@nist.gov\",\"type\":\"Primary\",\"cvssData\":{\"version\":\"3.1\",\"vectorString\":\"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H\",\"baseScore\":8.8,\"baseSeverity\":\"HIGH\",\"attackVector\":\"LOCAL\",\"attackComplexity\":\"LOW\",\"privilegesRequired\":\"LOW\",\"userInteraction\":\"NONE\",\"scope\":\"CHANGED\",\"confidentialityImpact\":\"HIGH\",\"integrityImpact\":\"HIGH\",\"availabilityImpact\":\"HIGH\"},\"exploitabilityScore\":2.0,\"impactScore\":6.0}],\"cvssMetricV2\":[{\"source\":\"nvd@nist.gov\",\"type\":\"Primary\",\"cvssData\":{\"version\":\"2.0\",\"vectorString\":\"AV:L/AC:L/Au:N/C:P/I:P/A:P\",\"baseScore\":4.6,\"accessVector\":\"LOCAL\",\"accessComplexity\":\"LOW\",\"authentication\":\"NONE\",\"confidentialityImpact\":\"PARTIAL\",\"integrityImpact\":\"PARTIAL\",\"availabilityImpact\":\"PARTIAL\"},\"baseSeverity\":\"MEDIUM\",\"exploitabilityScore\":3.9,\"impactScore\":6.4,\"acInsufInfo\":false,\"obtainAllPrivilege\":false,\"obtainUserPrivilege\":false,\"obtainOtherPrivilege\":false,\"userInteractionRequired\":false}]},\"weaknesses\":[{\"source\":\"security-advisories@github.com\",\"type\":\"Secondary\",\"description\":[{\"lang\":\"en\",\"value\":\"CWE-788\"}]},{\"source\":\"nvd@nist.gov\",\"type\":\"Secondary\",\"description\":[{\"lang\":\"en\",\"value\":\"CWE-125\"},{\"lang\":\"en\",\"value\":\"CWE-681\"}]}],\"configurations\":[{\"nodes\":[{\"operator\":\"OR\",\"negate\":false,\"cpeMatch\":[{\"vulnerable\":true,\"criteria\":\"cpe:2.3:a:bytecodealliance:cranelift-codegen:*:*:*:*:*:rust:*:*\",\"versionEndExcluding\":\"0.73.1\",\"matchCriteriaId\":\"D13A3F5D-ACAC-4E42-BD2B-A872C7BCC883\"}]}]}],\"references\":[{\"url\":\"https://crates.io/crates/cranelift-codegen\",\"source\":\"security-advisories@github.com\",\"tags\":[\"Product\",\"Third Party Advisory\"]},{\"url\":\"https://github.com/bytecodealliance/wasmtime/commit/95559c01aaa7c061088a433040f31e8291fb09d0\",\"source\":\"security-advisories@github.com\",\"tags\":[\"Patch\",\"Third Party Advisory\"]},{\"url\":\"https://github.com/bytecodealliance/wasmtime/security/advisories/GHSA-hpqh-2wqx-7qp5\",\"source\":\"security-advisories@github.com\",\"tags\":[\"Exploit\",\"Third Party Advisory\"]},{\"url\":\"https://www.fastly.com/security-advisories/memory-access-due-to-code-generation-flaw-in-cranelift-module\",\"source\":\"security-advisories@github.com\",\"tags\":[\"Third Party Advisory\"]},{\"url\":\"https://crates.io/crates/cranelift-codegen\",\"source\":\"af854a3a-2127-422b-91ae-364da2661108\",\"tags\":[\"Product\",\"Third Party Advisory\"]},{\"url\":\"https://github.com/bytecodealliance/wasmtime/commit/95559c01aaa7c061088a433040f31e8291fb09d0\",\"source\":\"af854a3a-2127-422b-91ae-364da2661108\",\"tags\":[\"Patch\",\"Third Party Advisory\"]},{\"url\":\"https://github.com/bytecodealliance/wasmtime/security/advisories/GHSA-hpqh-2wqx-7qp5\",\"source\":\"af854a3a-2127-422b-91ae-364da2661108\",\"tags\":[\"Exploit\",\"Third Party Advisory\"]},{\"url\":\"https://www.fastly.com/security-advisories/memory-access-due-to-code-generation-flaw-in-cranelift-module\",\"source\":\"af854a3a-2127-422b-91ae-364da2661108\",\"tags\":[\"Third Party Advisory\"]}]}}"
  }
}


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.