Vulnerabilites related to bytecodealliance - cranelift-codegen
Vulnerability from fkie_nvd
Published
2023-03-08 20:15
Modified
2024-11-21 07:51
Severity ?
9.9 (Critical) - CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H
9.9 (Critical) - CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H
9.9 (Critical) - CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H
Summary
wasmtime is a fast and secure runtime for WebAssembly. In affected versions wasmtime's code generator, Cranelift, has a bug on x86_64 targets where address-mode computation mistakenly would calculate a 35-bit effective address instead of WebAssembly's defined 33-bit effective address. This bug means that, with default codegen settings, a wasm-controlled load/store operation could read/write addresses up to 35 bits away from the base of linear memory. Due to this bug, however, addresses up to `0xffffffff * 8 + 0x7ffffffc = 36507222004 = ~34G` bytes away from the base of linear memory are possible from guest code. This means that the virtual memory 6G away from the base of linear memory up to ~34G away can be read/written by a malicious module. A guest module can, without the knowledge of the embedder, read/write memory in this region. The memory may belong to other WebAssembly instances when using the pooling allocator, for example. Affected embedders are recommended to analyze preexisting wasm modules to see if they're affected by the incorrect codegen rules and possibly correlate that with an anomalous number of traps during historical execution to locate possibly suspicious modules. The specific bug in Cranelift's x86_64 backend is that a WebAssembly address which is left-shifted by a constant amount from 1 to 3 will get folded into x86_64's addressing modes which perform shifts. For example `(i32.load (i32.shl (local.get 0) (i32.const 3)))` loads from the WebAssembly address `$local0 << 3`. When translated to Cranelift the `$local0 << 3` computation, a 32-bit value, is zero-extended to a 64-bit value and then added to the base address of linear memory. Cranelift would generate an instruction of the form `movl (%base, %local0, 8), %dst` which calculates `%base + %local0 << 3`. The bug here, however, is that the address computation happens with 64-bit values, where the `$local0 << 3` computation was supposed to be truncated to a a 32-bit value. This means that `%local0`, which can use up to 32-bits for an address, gets 3 extra bits of address space to be accessible via this `movl` instruction. The fix in Cranelift is to remove the erroneous lowering rules in the backend which handle these zero-extended expression. The above example is then translated to `movl %local0, %temp; shl $3, %temp; movl (%base, %temp), %dst` which correctly truncates the intermediate computation of `%local0 << 3` to 32-bits inside the `%temp` register which is then added to the `%base` value. Wasmtime version 4.0.1, 5.0.1, and 6.0.1 have been released and have all been patched to no longer contain the erroneous lowering rules. While updating Wasmtime is recommended, there are a number of possible workarounds that embedders can employ to mitigate this issue if updating is not possible. Note that none of these workarounds are on-by-default and require explicit configuration: 1. The `Config::static_memory_maximum_size(0)` option can be used to force all accesses to linear memory to be explicitly bounds-checked. This will perform a bounds check separately from the address-mode computation which correctly calculates the effective address of a load/store. Note that this can have a large impact on the execution performance of WebAssembly modules. 2. The `Config::static_memory_guard_size(1 << 36)` option can be used to greatly increase the guard pages placed after linear memory. This will guarantee that memory accesses up-to-34G away are guaranteed to be semantically correct by reserving unmapped memory for the instance. Note that this reserves a very large amount of virtual memory per-instances and can greatly reduce the maximum number of concurrent instances being run. 3. If using a non-x86_64 host is possible, then that will also work around this bug. This bug does not affect Wasmtime's or Cranelift's AArch64 backend, for example.
References
Impacted products
Vendor | Product | Version | |
---|---|---|---|
bytecodealliance | cranelift-codegen | * | |
bytecodealliance | cranelift-codegen | 0.92.0 | |
bytecodealliance | cranelift-codegen | 0.93.0 | |
bytecodealliance | wasmtime | * | |
bytecodealliance | wasmtime | 5.0.0 | |
bytecodealliance | wasmtime | 6.0.0 |
{ "configurations": [ { "nodes": [ { "cpeMatch": [ { "criteria": "cpe:2.3:a:bytecodealliance:cranelift-codegen:*:*:*:*:*:rust:*:*", "matchCriteriaId": "DBCFE132-FEDA-4A43-AE02-08E150E411D7", "versionEndExcluding": "0.91.1", "versionStartIncluding": "0.84.0", "vulnerable": true }, { "criteria": "cpe:2.3:a:bytecodealliance:cranelift-codegen:0.92.0:*:*:*:*:rust:*:*", "matchCriteriaId": "7D7B0DE4-0071-4056-A243-D0BB71963F93", "vulnerable": true }, { "criteria": "cpe:2.3:a:bytecodealliance:cranelift-codegen:0.93.0:*:*:*:*:rust:*:*", "matchCriteriaId": "0EC7D2FC-6423-45AE-8F82-A37F93C17285", "vulnerable": true }, { "criteria": "cpe:2.3:a:bytecodealliance:wasmtime:*:*:*:*:*:rust:*:*", "matchCriteriaId": "DD965E87-91DE-4FD2-8AED-37274050D01F", "versionEndExcluding": "4.0.1", "versionStartIncluding": "0.37.0", "vulnerable": true }, { "criteria": "cpe:2.3:a:bytecodealliance:wasmtime:5.0.0:*:*:*:*:rust:*:*", "matchCriteriaId": "87B4AC93-F648-4E7B-9FC7-53D885110E35", "vulnerable": true }, { "criteria": "cpe:2.3:a:bytecodealliance:wasmtime:6.0.0:*:*:*:*:rust:*:*", "matchCriteriaId": "A21E7233-1DAD-449F-A48F-05BE3DE8E2E0", "vulnerable": true } ], "negate": false, "operator": "OR" } ] } ], "cveTags": [], "descriptions": [ { "lang": "en", "value": "wasmtime is a fast and secure runtime for WebAssembly. In affected versions wasmtime\u0027s code generator, Cranelift, has a bug on x86_64 targets where address-mode computation mistakenly would calculate a 35-bit effective address instead of WebAssembly\u0027s defined 33-bit effective address. This bug means that, with default codegen settings, a wasm-controlled load/store operation could read/write addresses up to 35 bits away from the base of linear memory. Due to this bug, however, addresses up to `0xffffffff * 8 + 0x7ffffffc = 36507222004 = ~34G` bytes away from the base of linear memory are possible from guest code. This means that the virtual memory 6G away from the base of linear memory up to ~34G away can be read/written by a malicious module. A guest module can, without the knowledge of the embedder, read/write memory in this region. The memory may belong to other WebAssembly instances when using the pooling allocator, for example. Affected embedders are recommended to analyze preexisting wasm modules to see if they\u0027re affected by the incorrect codegen rules and possibly correlate that with an anomalous number of traps during historical execution to locate possibly suspicious modules. The specific bug in Cranelift\u0027s x86_64 backend is that a WebAssembly address which is left-shifted by a constant amount from 1 to 3 will get folded into x86_64\u0027s addressing modes which perform shifts. For example `(i32.load (i32.shl (local.get 0) (i32.const 3)))` loads from the WebAssembly address `$local0 \u003c\u003c 3`. When translated to Cranelift the `$local0 \u003c\u003c 3` computation, a 32-bit value, is zero-extended to a 64-bit value and then added to the base address of linear memory. Cranelift would generate an instruction of the form `movl (%base, %local0, 8), %dst` which calculates `%base + %local0 \u003c\u003c 3`. The bug here, however, is that the address computation happens with 64-bit values, where the `$local0 \u003c\u003c 3` computation was supposed to be truncated to a a 32-bit value. This means that `%local0`, which can use up to 32-bits for an address, gets 3 extra bits of address space to be accessible via this `movl` instruction. The fix in Cranelift is to remove the erroneous lowering rules in the backend which handle these zero-extended expression. The above example is then translated to `movl %local0, %temp; shl $3, %temp; movl (%base, %temp), %dst` which correctly truncates the intermediate computation of `%local0 \u003c\u003c 3` to 32-bits inside the `%temp` register which is then added to the `%base` value. Wasmtime version 4.0.1, 5.0.1, and 6.0.1 have been released and have all been patched to no longer contain the erroneous lowering rules. While updating Wasmtime is recommended, there are a number of possible workarounds that embedders can employ to mitigate this issue if updating is not possible. Note that none of these workarounds are on-by-default and require explicit configuration: 1. The `Config::static_memory_maximum_size(0)` option can be used to force all accesses to linear memory to be explicitly bounds-checked. This will perform a bounds check separately from the address-mode computation which correctly calculates the effective address of a load/store. Note that this can have a large impact on the execution performance of WebAssembly modules. 2. The `Config::static_memory_guard_size(1 \u003c\u003c 36)` option can be used to greatly increase the guard pages placed after linear memory. This will guarantee that memory accesses up-to-34G away are guaranteed to be semantically correct by reserving unmapped memory for the instance. Note that this reserves a very large amount of virtual memory per-instances and can greatly reduce the maximum number of concurrent instances being run. 3. If using a non-x86_64 host is possible, then that will also work around this bug. This bug does not affect Wasmtime\u0027s or Cranelift\u0027s AArch64 backend, for example.\n" } ], "id": "CVE-2023-26489", "lastModified": "2024-11-21T07:51:37.430", "metrics": { "cvssMetricV31": [ { "cvssData": { "attackComplexity": "LOW", "attackVector": "NETWORK", "availabilityImpact": "HIGH", "baseScore": 9.9, "baseSeverity": "CRITICAL", "confidentialityImpact": "HIGH", "integrityImpact": "HIGH", "privilegesRequired": "LOW", "scope": "CHANGED", "userInteraction": "NONE", "vectorString": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H", "version": "3.1" }, "exploitabilityScore": 3.1, "impactScore": 6.0, "source": "security-advisories@github.com", "type": "Secondary" }, { "cvssData": { "attackComplexity": "LOW", "attackVector": "NETWORK", "availabilityImpact": "HIGH", "baseScore": 9.9, "baseSeverity": "CRITICAL", "confidentialityImpact": "HIGH", "integrityImpact": "HIGH", "privilegesRequired": "LOW", "scope": "CHANGED", "userInteraction": "NONE", "vectorString": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H", "version": "3.1" }, "exploitabilityScore": 3.1, "impactScore": 6.0, "source": "nvd@nist.gov", "type": "Primary" } ] }, "published": "2023-03-08T20:15:09.583", "references": [ { "source": "security-advisories@github.com", "tags": [ "Product" ], "url": "https://docs.rs/wasmtime/latest/wasmtime/struct.Config.html#method.static_memory_guard_size" }, { "source": "security-advisories@github.com", "tags": [ "Product" ], "url": "https://docs.rs/wasmtime/latest/wasmtime/struct.Config.html#method.static_memory_maximum_size" }, { "source": "security-advisories@github.com", "tags": [ "Patch" ], "url": "https://github.com/bytecodealliance/wasmtime/commit/63fb30e4b4415455d47b3da5a19d79c12f4f2d1f" }, { "source": "security-advisories@github.com", "tags": [ "Mitigation", "Patch", "Vendor Advisory" ], "url": "https://github.com/bytecodealliance/wasmtime/security/advisories/GHSA-ff4p-7xrq-q5r8" }, { "source": "security-advisories@github.com", "tags": [ "Mailing List", "Release Notes", "Vendor Advisory" ], "url": "https://groups.google.com/a/bytecodealliance.org/g/sec-announce/c/Mov-ItrNJsQ" }, { "source": "af854a3a-2127-422b-91ae-364da2661108", "tags": [ "Product" ], "url": "https://docs.rs/wasmtime/latest/wasmtime/struct.Config.html#method.static_memory_guard_size" }, { "source": "af854a3a-2127-422b-91ae-364da2661108", "tags": [ "Product" ], "url": "https://docs.rs/wasmtime/latest/wasmtime/struct.Config.html#method.static_memory_maximum_size" }, { "source": "af854a3a-2127-422b-91ae-364da2661108", "tags": [ "Patch" ], "url": "https://github.com/bytecodealliance/wasmtime/commit/63fb30e4b4415455d47b3da5a19d79c12f4f2d1f" }, { "source": "af854a3a-2127-422b-91ae-364da2661108", "tags": [ "Mitigation", "Patch", "Vendor Advisory" ], "url": "https://github.com/bytecodealliance/wasmtime/security/advisories/GHSA-ff4p-7xrq-q5r8" }, { "source": "af854a3a-2127-422b-91ae-364da2661108", "tags": [ "Mailing List", "Release Notes", "Vendor Advisory" ], "url": "https://groups.google.com/a/bytecodealliance.org/g/sec-announce/c/Mov-ItrNJsQ" } ], "sourceIdentifier": "security-advisories@github.com", "vulnStatus": "Modified", "weaknesses": [ { "description": [ { "lang": "en", "value": "CWE-125" }, { "lang": "en", "value": "CWE-787" } ], "source": "security-advisories@github.com", "type": "Primary" } ] }
Vulnerability from fkie_nvd
Published
2022-07-21 04:15
Modified
2024-11-21 07:03
Severity ?
6.4 (Medium) - CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:L/A:L
8.8 (High) - CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
8.8 (High) - CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Summary
Wasmtime is a standalone runtime for WebAssembly. There is a bug in the Wasmtime's code generator, Cranelift, where functions using reference types may be incorrectly missing metadata required for runtime garbage collection. This means that if a GC happens at runtime then the GC pass will mistakenly think these functions do not have live references to GC'd values, reclaiming them and deallocating them. The function will then subsequently continue to use the values assuming they had not been GC'd, leading later to a use-after-free. This bug was introduced in the migration to the `regalloc2` register allocator that occurred in the Wasmtime 0.37.0 release on 2022-05-20. This bug has been patched and users should upgrade to Wasmtime version 0.38.2. Mitigations for this issue can be achieved by disabling the reference types proposal by passing `false` to `wasmtime::Config::wasm_reference_types` or downgrading to Wasmtime 0.36.0 or prior.
References
▼ | URL | Tags | |
---|---|---|---|
security-advisories@github.com | https://github.com/WebAssembly/reference-types | Third Party Advisory | |
security-advisories@github.com | https://github.com/bytecodealliance/wasmtime/ | Product, Third Party Advisory | |
security-advisories@github.com | https://github.com/bytecodealliance/wasmtime/security/advisories/GHSA-5fhj-g3p3-pq9g | Mitigation, Third Party Advisory | |
af854a3a-2127-422b-91ae-364da2661108 | https://github.com/WebAssembly/reference-types | Third Party Advisory | |
af854a3a-2127-422b-91ae-364da2661108 | https://github.com/bytecodealliance/wasmtime/ | Product, Third Party Advisory | |
af854a3a-2127-422b-91ae-364da2661108 | https://github.com/bytecodealliance/wasmtime/security/advisories/GHSA-5fhj-g3p3-pq9g | Mitigation, Third Party Advisory |
Impacted products
Vendor | Product | Version | |
---|---|---|---|
bytecodealliance | cranelift-codegen | * | |
bytecodealliance | wasmtime | * |
{ "configurations": [ { "nodes": [ { "cpeMatch": [ { "criteria": "cpe:2.3:a:bytecodealliance:cranelift-codegen:*:*:*:*:*:rust:*:*", "matchCriteriaId": "5320439C-4F61-46CA-9952-B61C1D5C8F3A", "versionEndExcluding": "0.85.2", "versionStartIncluding": "0.84.0", "vulnerable": true }, { "criteria": "cpe:2.3:a:bytecodealliance:wasmtime:*:*:*:*:*:rust:*:*", "matchCriteriaId": "53584B86-F94A-4F0C-B741-D526671C2B23", "versionEndExcluding": "0.38.2", "versionStartIncluding": "0.37.0", "vulnerable": true } ], "negate": false, "operator": "OR" } ] } ], "cveTags": [], "descriptions": [ { "lang": "en", "value": "Wasmtime is a standalone runtime for WebAssembly. There is a bug in the Wasmtime\u0027s code generator, Cranelift, where functions using reference types may be incorrectly missing metadata required for runtime garbage collection. This means that if a GC happens at runtime then the GC pass will mistakenly think these functions do not have live references to GC\u0027d values, reclaiming them and deallocating them. The function will then subsequently continue to use the values assuming they had not been GC\u0027d, leading later to a use-after-free. This bug was introduced in the migration to the `regalloc2` register allocator that occurred in the Wasmtime 0.37.0 release on 2022-05-20. This bug has been patched and users should upgrade to Wasmtime version 0.38.2. Mitigations for this issue can be achieved by disabling the reference types proposal by passing `false` to `wasmtime::Config::wasm_reference_types` or downgrading to Wasmtime 0.36.0 or prior." }, { "lang": "es", "value": "Se presenta un error en el generador de c\u00f3digo de Wasmtime, Cranelift, en el que las funciones que usan tipos de referencia pueden carecer incorrectamente de los metadatos necesarios para la recolecci\u00f3n de basura en tiempo de ejecuci\u00f3n. Esto significa que si es producida una GC en tiempo de ejecuci\u00f3n, el pase de GC pensar\u00e1 err\u00f3neamente que estas funciones no presentan referencias vivas a los valores de la GC, reclam\u00e1ndolos y reasign\u00e1ndolos. La funci\u00f3n continuar\u00e1 entonces usando los valores asumiendo que no han sido GC\u0027d, conllevando m\u00e1s tarde a un uso de memoria previamente liberada. Este bug fue introducido en la migraci\u00f3n al asignador de registros \"regalloc2\" que ocurri\u00f3 en Wasmtime versi\u00f3n 0.37.0 del 20-05-2022. Este bug ha sido parcheado y los usuarios deber\u00edan actualizar a Wasmtime versi\u00f3n 0.38.2. La mitigaci\u00f3n de este problema puede lograrse al hacer una de las siguientes cosas: * Deshabilitar la propuesta de tipos de referencia pasando \"false\" a [\"wasmtime::Config::wasm_reference_types\"](https://docs.rs/wasmtime/0.38.0/wasmtime/struct.Config.html#method.wasm_reference_types). * Desactualizar a Wasmtime versi\u00f3n 0.36.0 o anterior" } ], "id": "CVE-2022-31146", "lastModified": "2024-11-21T07:03:59.603", "metrics": { "cvssMetricV31": [ { "cvssData": { "attackComplexity": "HIGH", "attackVector": "NETWORK", "availabilityImpact": "LOW", "baseScore": 6.4, "baseSeverity": "MEDIUM", "confidentialityImpact": "HIGH", "integrityImpact": "LOW", "privilegesRequired": "LOW", "scope": "UNCHANGED", "userInteraction": "NONE", "vectorString": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:L/A:L", "version": "3.1" }, "exploitabilityScore": 1.6, "impactScore": 4.7, "source": "security-advisories@github.com", "type": "Secondary" }, { "cvssData": { "attackComplexity": "LOW", "attackVector": "NETWORK", "availabilityImpact": "HIGH", "baseScore": 8.8, "baseSeverity": "HIGH", "confidentialityImpact": "HIGH", "integrityImpact": "HIGH", "privilegesRequired": "LOW", "scope": "UNCHANGED", "userInteraction": "NONE", "vectorString": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H", "version": "3.1" }, "exploitabilityScore": 2.8, "impactScore": 5.9, "source": "nvd@nist.gov", "type": "Primary" } ] }, "published": "2022-07-21T04:15:11.937", "references": [ { "source": "security-advisories@github.com", "tags": [ "Third Party Advisory" ], "url": "https://github.com/WebAssembly/reference-types" }, { "source": "security-advisories@github.com", "tags": [ "Product", "Third Party Advisory" ], "url": "https://github.com/bytecodealliance/wasmtime/" }, { "source": "security-advisories@github.com", "tags": [ "Mitigation", "Third Party Advisory" ], "url": "https://github.com/bytecodealliance/wasmtime/security/advisories/GHSA-5fhj-g3p3-pq9g" }, { "source": "af854a3a-2127-422b-91ae-364da2661108", "tags": [ "Third Party Advisory" ], "url": "https://github.com/WebAssembly/reference-types" }, { "source": "af854a3a-2127-422b-91ae-364da2661108", "tags": [ "Product", "Third Party Advisory" ], "url": "https://github.com/bytecodealliance/wasmtime/" }, { "source": "af854a3a-2127-422b-91ae-364da2661108", "tags": [ "Mitigation", "Third Party Advisory" ], "url": "https://github.com/bytecodealliance/wasmtime/security/advisories/GHSA-5fhj-g3p3-pq9g" } ], "sourceIdentifier": "security-advisories@github.com", "vulnStatus": "Modified", "weaknesses": [ { "description": [ { "lang": "en", "value": "CWE-416" } ], "source": "security-advisories@github.com", "type": "Primary" } ] }
Vulnerability from fkie_nvd
Published
2022-06-28 00:15
Modified
2024-11-21 07:03
Severity ?
4.8 (Medium) - CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:L
5.6 (Medium) - CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:L
5.6 (Medium) - CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:L
Summary
Wasmtime is a standalone runtime for WebAssembly. In affected versions wasmtime's implementation of the SIMD proposal for WebAssembly on x86_64 contained two distinct bugs in the instruction lowerings implemented in Cranelift. The aarch64 implementation of the simd proposal is not affected. The bugs were presented in the `i8x16.swizzle` and `select` WebAssembly instructions. The `select` instruction is only affected when the inputs are of `v128` type. The correspondingly affected Cranelift instructions were `swizzle` and `select`. The `swizzle` instruction lowering in Cranelift erroneously overwrote the mask input register which could corrupt a constant value, for example. This means that future uses of the same constant may see a different value than the constant itself. The `select` instruction lowering in Cranelift wasn't correctly implemented for vector types that are 128-bits wide. When the condition was 0 the wrong instruction was used to move the correct input to the output of the instruction meaning that only the low 32 bits were moved and the upper 96 bits of the result were left as whatever the register previously contained (instead of the input being moved from). The `select` instruction worked correctly if the condition was nonzero, however. This bug in Wasmtime's implementation of these instructions on x86_64 represents an incorrect implementation of the specified semantics of these instructions according to the WebAssembly specification. The impact of this is benign for hosts running WebAssembly but represents possible vulnerabilities within the execution of a guest program. For example a WebAssembly program could take unintended branches or materialize incorrect values internally which runs the risk of exposing the program itself to other related vulnerabilities which can occur from miscompilations. We have released Wasmtime 0.38.1 and cranelift-codegen (and other associated cranelift crates) 0.85.1 which contain the corrected implementations of these two instructions in Cranelift. If upgrading is not an option for you at this time, you can avoid the vulnerability by disabling the Wasm simd proposal. Additionally the bug is only present on x86_64 hosts. Other aarch64 hosts are not affected. Note that s390x hosts don't yet implement the simd proposal and are not affected.
References
Impacted products
Vendor | Product | Version | |
---|---|---|---|
bytecodealliance | cranelift-codegen | * | |
bytecodealliance | wasmtime | * |
{ "configurations": [ { "nodes": [ { "cpeMatch": [ { "criteria": "cpe:2.3:a:bytecodealliance:cranelift-codegen:*:*:*:*:*:rust:*:*", "matchCriteriaId": "A97CC30F-E8C8-4589-91CB-8423704C5C5D", "versionEndExcluding": "0.85.0", "vulnerable": true }, { "criteria": "cpe:2.3:a:bytecodealliance:wasmtime:*:*:*:*:*:rust:*:*", "matchCriteriaId": "B9C6651A-233F-40DD-AB1B-1A435F97728B", "versionEndExcluding": "0.38.1", "vulnerable": true } ], "negate": false, "operator": "OR" } ] } ], "cveTags": [], "descriptions": [ { "lang": "en", "value": "Wasmtime is a standalone runtime for WebAssembly. In affected versions wasmtime\u0027s implementation of the SIMD proposal for WebAssembly on x86_64 contained two distinct bugs in the instruction lowerings implemented in Cranelift. The aarch64 implementation of the simd proposal is not affected. The bugs were presented in the `i8x16.swizzle` and `select` WebAssembly instructions. The `select` instruction is only affected when the inputs are of `v128` type. The correspondingly affected Cranelift instructions were `swizzle` and `select`. The `swizzle` instruction lowering in Cranelift erroneously overwrote the mask input register which could corrupt a constant value, for example. This means that future uses of the same constant may see a different value than the constant itself. The `select` instruction lowering in Cranelift wasn\u0027t correctly implemented for vector types that are 128-bits wide. When the condition was 0 the wrong instruction was used to move the correct input to the output of the instruction meaning that only the low 32 bits were moved and the upper 96 bits of the result were left as whatever the register previously contained (instead of the input being moved from). The `select` instruction worked correctly if the condition was nonzero, however. This bug in Wasmtime\u0027s implementation of these instructions on x86_64 represents an incorrect implementation of the specified semantics of these instructions according to the WebAssembly specification. The impact of this is benign for hosts running WebAssembly but represents possible vulnerabilities within the execution of a guest program. For example a WebAssembly program could take unintended branches or materialize incorrect values internally which runs the risk of exposing the program itself to other related vulnerabilities which can occur from miscompilations. We have released Wasmtime 0.38.1 and cranelift-codegen (and other associated cranelift crates) 0.85.1 which contain the corrected implementations of these two instructions in Cranelift. If upgrading is not an option for you at this time, you can avoid the vulnerability by disabling the Wasm simd proposal. Additionally the bug is only present on x86_64 hosts. Other aarch64 hosts are not affected. Note that s390x hosts don\u0027t yet implement the simd proposal and are not affected." }, { "lang": "es", "value": "Wasmtime es un runtime independiente para WebAssembly. En las versiones afectadas, la implementaci\u00f3n de wasmtime de la propuesta SIMD para WebAssembly en x86_64 conten\u00eda dos errores distintos en los rebajes de instrucciones implementados en Cranelift. La implementaci\u00f3n aarch64 de la propuesta simd no est\u00e1 afectada. Los errores eran presentados en las instrucciones \"i8x16.swizzle\" y \"select\" de WebAssembly. La instrucci\u00f3n \"select\" s\u00f3lo est\u00e1 afectada cuando las entradas son de tipo \"v128\". Las instrucciones de Cranelift afectadas son \"swizzle\" y \"select\". La instrucci\u00f3n \"swizzle\" que bajaba en Cranelift sobrescrib\u00eda err\u00f3neamente el registro de entrada de la m\u00e1scara, lo que pod\u00eda corromper un valor constante, por ejemplo. Esto significa que los futuros usos de la misma constante pueden ver un valor diferente al de la propia constante. La instrucci\u00f3n \"select\" que baja en Cranelift no estaba correctamente implementada para los tipos de vectores que presentan 128 bits de ancho. Cuando la condici\u00f3n era 0, es usada la instrucci\u00f3n incorrecta para mover la entrada correcta a la salida de la instrucci\u00f3n, lo que significaba que s\u00f3lo eran movidos los 32 bits inferiores y los 96 bits superiores del resultado quedaban como lo que conten\u00eda el registro anteriormente (en lugar de la entrada que era movida). Sin embargo, la instrucci\u00f3n \"select\" funcionaba correctamente si la condici\u00f3n era distinta de cero. Este error en la implementaci\u00f3n de Wasmtime de estas instrucciones en x86_64 representa una implementaci\u00f3n incorrecta de la sem\u00e1ntica especificada de estas instrucciones seg\u00fan la especificaci\u00f3n de WebAssembly. El impacto de esto es benigno para los hosts que ejecutan WebAssembly pero representa posibles vulnerabilidades dentro de la ejecuci\u00f3n de un programa invitado. Por ejemplo, un programa WebAssembly podr\u00eda tomar ramas no deseadas o materializar valores incorrectos internamente, lo que corre el riesgo de exponer el propio programa a otras vulnerabilidades relacionadas que pueden ocurrir por compilaciones err\u00f3neas. Hemos publicado Wasmtime versi\u00f3n 0.38.1 y cranelift-codegen (y otras cajas asociadas de cranelift) versi\u00f3n 0.85.1 que contienen las implementaciones corregidas de estas dos instrucciones en Cranelift. Si la actualizaci\u00f3n no es una opci\u00f3n para usted en este momento, puede evitar la vulnerabilidad al deshabilitar la propuesta Wasm simd. Adem\u00e1s, el bug s\u00f3lo est\u00e1 presente en hosts x86_64. Otros hosts aarch64 no est\u00e1n afectados. Tenga en cuenta que los hosts s390x a\u00fan no implementan la propuesta simd y no est\u00e1n afectados" } ], "id": "CVE-2022-31104", "lastModified": "2024-11-21T07:03:54.137", "metrics": { "cvssMetricV2": [ { "acInsufInfo": false, "baseSeverity": "MEDIUM", "cvssData": { "accessComplexity": "MEDIUM", "accessVector": "NETWORK", "authentication": "NONE", "availabilityImpact": "PARTIAL", "baseScore": 6.8, "confidentialityImpact": "PARTIAL", "integrityImpact": "PARTIAL", "vectorString": "AV:N/AC:M/Au:N/C:P/I:P/A:P", "version": "2.0" }, "exploitabilityScore": 8.6, "impactScore": 6.4, "obtainAllPrivilege": false, "obtainOtherPrivilege": false, "obtainUserPrivilege": false, "source": "nvd@nist.gov", "type": "Primary", "userInteractionRequired": false } ], "cvssMetricV31": [ { "cvssData": { "attackComplexity": "HIGH", "attackVector": "NETWORK", "availabilityImpact": "LOW", "baseScore": 4.8, "baseSeverity": "MEDIUM", "confidentialityImpact": "NONE", "integrityImpact": "LOW", "privilegesRequired": "NONE", "scope": "UNCHANGED", "userInteraction": "NONE", "vectorString": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:L", "version": "3.1" }, "exploitabilityScore": 2.2, "impactScore": 2.5, "source": "security-advisories@github.com", "type": "Secondary" }, { "cvssData": { "attackComplexity": "HIGH", "attackVector": "NETWORK", "availabilityImpact": "LOW", "baseScore": 5.6, "baseSeverity": "MEDIUM", "confidentialityImpact": "LOW", "integrityImpact": "LOW", "privilegesRequired": "NONE", "scope": "UNCHANGED", "userInteraction": "NONE", "vectorString": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:L", "version": "3.1" }, "exploitabilityScore": 2.2, "impactScore": 3.4, "source": "nvd@nist.gov", "type": "Primary" } ] }, "published": "2022-06-28T00:15:08.177", "references": [ { "source": "security-advisories@github.com", "tags": [ "Third Party Advisory" ], "url": "https://docs.rs/wasmtime/latest/wasmtime/struct.Config.html#method.wasm_simd" }, { "source": "security-advisories@github.com", "tags": [ "Issue Tracking", "Patch", "Third Party Advisory" ], "url": "https://github.com/bytecodealliance/wasmtime/pull/4317" }, { "source": "security-advisories@github.com", "tags": [ "Issue Tracking", "Patch", "Third Party Advisory" ], "url": "https://github.com/bytecodealliance/wasmtime/pull/4318" }, { "source": "security-advisories@github.com", "tags": [ "Mitigation", "Third Party Advisory" ], "url": "https://github.com/bytecodealliance/wasmtime/security/advisories/GHSA-jqwc-c49r-4w2x" }, { "source": "security-advisories@github.com", "tags": [ "Third Party Advisory" ], "url": "https://github.com/webassembly/simd" }, { "source": "security-advisories@github.com", "tags": [ "Third Party Advisory" ], "url": "https://webassembly.github.io/spec/" }, { "source": "af854a3a-2127-422b-91ae-364da2661108", "tags": [ "Third Party Advisory" ], "url": "https://docs.rs/wasmtime/latest/wasmtime/struct.Config.html#method.wasm_simd" }, { "source": "af854a3a-2127-422b-91ae-364da2661108", "tags": [ "Issue Tracking", "Patch", "Third Party Advisory" ], "url": "https://github.com/bytecodealliance/wasmtime/pull/4317" }, { "source": "af854a3a-2127-422b-91ae-364da2661108", "tags": [ "Issue Tracking", "Patch", "Third Party Advisory" ], "url": "https://github.com/bytecodealliance/wasmtime/pull/4318" }, { "source": "af854a3a-2127-422b-91ae-364da2661108", "tags": [ "Mitigation", "Third Party Advisory" ], "url": "https://github.com/bytecodealliance/wasmtime/security/advisories/GHSA-jqwc-c49r-4w2x" }, { "source": "af854a3a-2127-422b-91ae-364da2661108", "tags": [ "Third Party Advisory" ], "url": "https://github.com/webassembly/simd" }, { "source": "af854a3a-2127-422b-91ae-364da2661108", "tags": [ "Third Party Advisory" ], "url": "https://webassembly.github.io/spec/" } ], "sourceIdentifier": "security-advisories@github.com", "vulnStatus": "Modified", "weaknesses": [ { "description": [ { "lang": "en", "value": "CWE-682" } ], "source": "security-advisories@github.com", "type": "Primary" } ] }
Vulnerability from fkie_nvd
Published
2023-03-08 21:15
Modified
2024-11-21 07:52
Severity ?
3.1 (Low) - CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:N/I:L/A:N
4.3 (Medium) - CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N
4.3 (Medium) - CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N
Summary
wasmtime is a fast and secure runtime for WebAssembly. Wasmtime's code generation backend, Cranelift, has a bug on x86_64 platforms for the WebAssembly `i8x16.select` instruction which will produce the wrong results when the same operand is provided to the instruction and some of the selected indices are greater than 16. There is an off-by-one error in the calculation of the mask to the `pshufb` instruction which causes incorrect results to be returned if lanes are selected from the second vector. This codegen bug has been fixed in Wasmtiem 6.0.1, 5.0.1, and 4.0.1. Users are recommended to upgrade to these updated versions. If upgrading is not an option for you at this time, you can avoid this miscompilation by disabling the Wasm simd proposal. Additionally the bug is only present on x86_64 hosts. Other platforms such as AArch64 and s390x are not affected.
References
Impacted products
Vendor | Product | Version | |
---|---|---|---|
bytecodealliance | cranelift-codegen | * | |
bytecodealliance | cranelift-codegen | 0.92.0 | |
bytecodealliance | cranelift-codegen | 0.93.0 | |
bytecodealliance | wasmtime | * | |
bytecodealliance | wasmtime | 5.0.0 | |
bytecodealliance | wasmtime | 6.0.0 |
{ "configurations": [ { "nodes": [ { "cpeMatch": [ { "criteria": "cpe:2.3:a:bytecodealliance:cranelift-codegen:*:*:*:*:*:rust:*:*", "matchCriteriaId": "DBCFE132-FEDA-4A43-AE02-08E150E411D7", "versionEndExcluding": "0.91.1", "versionStartIncluding": "0.84.0", "vulnerable": true }, { "criteria": "cpe:2.3:a:bytecodealliance:cranelift-codegen:0.92.0:*:*:*:*:rust:*:*", "matchCriteriaId": "7D7B0DE4-0071-4056-A243-D0BB71963F93", "vulnerable": true }, { "criteria": "cpe:2.3:a:bytecodealliance:cranelift-codegen:0.93.0:*:*:*:*:rust:*:*", "matchCriteriaId": "0EC7D2FC-6423-45AE-8F82-A37F93C17285", "vulnerable": true }, { "criteria": "cpe:2.3:a:bytecodealliance:wasmtime:*:*:*:*:*:rust:*:*", "matchCriteriaId": "DD965E87-91DE-4FD2-8AED-37274050D01F", "versionEndExcluding": "4.0.1", "versionStartIncluding": "0.37.0", "vulnerable": true }, { "criteria": "cpe:2.3:a:bytecodealliance:wasmtime:5.0.0:*:*:*:*:rust:*:*", "matchCriteriaId": "87B4AC93-F648-4E7B-9FC7-53D885110E35", "vulnerable": true }, { "criteria": "cpe:2.3:a:bytecodealliance:wasmtime:6.0.0:*:*:*:*:rust:*:*", "matchCriteriaId": "A21E7233-1DAD-449F-A48F-05BE3DE8E2E0", "vulnerable": true } ], "negate": false, "operator": "OR" } ] } ], "cveTags": [], "descriptions": [ { "lang": "en", "value": "wasmtime is a fast and secure runtime for WebAssembly. Wasmtime\u0027s code generation backend, Cranelift, has a bug on x86_64 platforms for the WebAssembly `i8x16.select` instruction which will produce the wrong results when the same operand is provided to the instruction and some of the selected indices are greater than 16. There is an off-by-one error in the calculation of the mask to the `pshufb` instruction which causes incorrect results to be returned if lanes are selected from the second vector. This codegen bug has been fixed in Wasmtiem 6.0.1, 5.0.1, and 4.0.1. Users are recommended to upgrade to these updated versions. If upgrading is not an option for you at this time, you can avoid this miscompilation by disabling the Wasm simd proposal. Additionally the bug is only present on x86_64 hosts. Other platforms such as AArch64 and s390x are not affected." } ], "id": "CVE-2023-27477", "lastModified": "2024-11-21T07:52:58.970", "metrics": { "cvssMetricV31": [ { "cvssData": { "attackComplexity": "HIGH", "attackVector": "NETWORK", "availabilityImpact": "NONE", "baseScore": 3.1, "baseSeverity": "LOW", "confidentialityImpact": "NONE", "integrityImpact": "LOW", "privilegesRequired": "LOW", "scope": "UNCHANGED", "userInteraction": "NONE", "vectorString": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:N/I:L/A:N", "version": "3.1" }, "exploitabilityScore": 1.6, "impactScore": 1.4, "source": "security-advisories@github.com", "type": "Secondary" }, { "cvssData": { "attackComplexity": "LOW", "attackVector": "NETWORK", "availabilityImpact": "NONE", "baseScore": 4.3, "baseSeverity": "MEDIUM", "confidentialityImpact": "NONE", "integrityImpact": "LOW", "privilegesRequired": "LOW", "scope": "UNCHANGED", "userInteraction": "NONE", "vectorString": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N", "version": "3.1" }, "exploitabilityScore": 2.8, "impactScore": 1.4, "source": "nvd@nist.gov", "type": "Primary" } ] }, "published": "2023-03-08T21:15:11.010", "references": [ { "source": "security-advisories@github.com", "tags": [ "Product" ], "url": "https://docs.rs/wasmtime/latest/wasmtime/struct.Config.html#method.wasm_simd" }, { "source": "security-advisories@github.com", "tags": [ "Patch" ], "url": "https://github.com/bytecodealliance/wasmtime/commit/5dc2bbccbb363e474d2c9a1b8e38a89a43bbd5d1" }, { "source": "security-advisories@github.com", "tags": [ "Mitigation", "Patch", "Vendor Advisory" ], "url": "https://github.com/bytecodealliance/wasmtime/security/advisories/GHSA-xm67-587q-r2vw" }, { "source": "security-advisories@github.com", "tags": [ "Not Applicable" ], "url": "https://github.com/webassembly/simd" }, { "source": "security-advisories@github.com", "tags": [ "Mailing List", "Release Notes", "Vendor Advisory" ], "url": "https://groups.google.com/a/bytecodealliance.org/g/sec-announce/c/Mov-ItrNJsQ" }, { "source": "af854a3a-2127-422b-91ae-364da2661108", "tags": [ "Product" ], "url": "https://docs.rs/wasmtime/latest/wasmtime/struct.Config.html#method.wasm_simd" }, { "source": "af854a3a-2127-422b-91ae-364da2661108", "tags": [ "Patch" ], "url": "https://github.com/bytecodealliance/wasmtime/commit/5dc2bbccbb363e474d2c9a1b8e38a89a43bbd5d1" }, { "source": "af854a3a-2127-422b-91ae-364da2661108", "tags": [ "Mitigation", "Patch", "Vendor Advisory" ], "url": "https://github.com/bytecodealliance/wasmtime/security/advisories/GHSA-xm67-587q-r2vw" }, { "source": "af854a3a-2127-422b-91ae-364da2661108", "tags": [ "Not Applicable" ], "url": "https://github.com/webassembly/simd" }, { "source": "af854a3a-2127-422b-91ae-364da2661108", "tags": [ "Mailing List", "Release Notes", "Vendor Advisory" ], "url": "https://groups.google.com/a/bytecodealliance.org/g/sec-announce/c/Mov-ItrNJsQ" } ], "sourceIdentifier": "security-advisories@github.com", "vulnStatus": "Modified", "weaknesses": [ { "description": [ { "lang": "en", "value": "CWE-193" } ], "source": "security-advisories@github.com", "type": "Primary" } ] }
Vulnerability from fkie_nvd
Published
2021-05-24 16:15
Modified
2024-11-21 06:07
Severity ?
7.2 (High) - CVSS:3.1/AV:L/AC:H/PR:L/UI:R/S:C/C:H/I:H/A:N
8.8 (High) - CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H
8.8 (High) - CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H
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
Impacted products
Vendor | Product | Version | |
---|---|---|---|
bytecodealliance | cranelift-codegen | * |
{ "configurations": [ { "nodes": [ { "cpeMatch": [ { "criteria": "cpe:2.3:a:bytecodealliance:cranelift-codegen:*:*:*:*:*:rust:*:*", "matchCriteriaId": "D13A3F5D-ACAC-4E42-BD2B-A872C7BCC883", "versionEndExcluding": "0.73.1", "vulnerable": true } ], "negate": false, "operator": "OR" } ] } ], "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" } ], "id": "CVE-2021-32629", "lastModified": "2024-11-21T06:07:24.877", "metrics": { "cvssMetricV2": [ { "acInsufInfo": false, "baseSeverity": "MEDIUM", "cvssData": { "accessComplexity": "LOW", "accessVector": "LOCAL", "authentication": "NONE", "availabilityImpact": "PARTIAL", "baseScore": 4.6, "confidentialityImpact": "PARTIAL", "integrityImpact": "PARTIAL", "vectorString": "AV:L/AC:L/Au:N/C:P/I:P/A:P", "version": "2.0" }, "exploitabilityScore": 3.9, "impactScore": 6.4, "obtainAllPrivilege": false, "obtainOtherPrivilege": false, "obtainUserPrivilege": false, "source": "nvd@nist.gov", "type": "Primary", "userInteractionRequired": false } ], "cvssMetricV31": [ { "cvssData": { "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" }, "exploitabilityScore": 0.8, "impactScore": 5.8, "source": "security-advisories@github.com", "type": "Secondary" }, { "cvssData": { "attackComplexity": "LOW", "attackVector": "LOCAL", "availabilityImpact": "HIGH", "baseScore": 8.8, "baseSeverity": "HIGH", "confidentialityImpact": "HIGH", "integrityImpact": "HIGH", "privilegesRequired": "LOW", "scope": "CHANGED", "userInteraction": "NONE", "vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H", "version": "3.1" }, "exploitabilityScore": 2.0, "impactScore": 6.0, "source": "nvd@nist.gov", "type": "Primary" } ] }, "published": "2021-05-24T16:15:08.087", "references": [ { "source": "security-advisories@github.com", "tags": [ "Product", "Third Party Advisory" ], "url": "https://crates.io/crates/cranelift-codegen" }, { "source": "security-advisories@github.com", "tags": [ "Patch", "Third Party Advisory" ], "url": "https://github.com/bytecodealliance/wasmtime/commit/95559c01aaa7c061088a433040f31e8291fb09d0" }, { "source": "security-advisories@github.com", "tags": [ "Exploit", "Third Party Advisory" ], "url": "https://github.com/bytecodealliance/wasmtime/security/advisories/GHSA-hpqh-2wqx-7qp5" }, { "source": "security-advisories@github.com", "tags": [ "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": [ "Product", "Third Party Advisory" ], "url": "https://crates.io/crates/cranelift-codegen" }, { "source": "af854a3a-2127-422b-91ae-364da2661108", "tags": [ "Patch", "Third Party Advisory" ], "url": "https://github.com/bytecodealliance/wasmtime/commit/95559c01aaa7c061088a433040f31e8291fb09d0" }, { "source": "af854a3a-2127-422b-91ae-364da2661108", "tags": [ "Exploit", "Third Party Advisory" ], "url": "https://github.com/bytecodealliance/wasmtime/security/advisories/GHSA-hpqh-2wqx-7qp5" }, { "source": "af854a3a-2127-422b-91ae-364da2661108", "tags": [ "Third Party Advisory" ], "url": "https://www.fastly.com/security-advisories/memory-access-due-to-code-generation-flaw-in-cranelift-module" } ], "sourceIdentifier": "security-advisories@github.com", "vulnStatus": "Modified", "weaknesses": [ { "description": [ { "lang": "en", "value": "CWE-788" } ], "source": "security-advisories@github.com", "type": "Secondary" }, { "description": [ { "lang": "en", "value": "CWE-125" }, { "lang": "en", "value": "CWE-681" } ], "source": "nvd@nist.gov", "type": "Primary" } ] }
Vulnerability from fkie_nvd
Published
2022-07-22 04:15
Modified
2024-11-21 07:04
Severity ?
5.9 (Medium) - CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N
7.5 (High) - CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N
7.5 (High) - CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N
Summary
Wasmtime is a standalone runtime for WebAssembly. There is a bug in Wasmtime's code generator, Cranelift, for AArch64 targets where constant divisors can result in incorrect division results at runtime. This affects Wasmtime prior to version 0.38.2 and Cranelift prior to 0.85.2. This issue only affects the AArch64 platform. Other platforms are not affected. The translation rules for constants did not take into account whether sign or zero-extension should happen which resulted in an incorrect value being placed into a register when a division was encountered. The impact of this bug is that programs executing within the WebAssembly sandbox would not behave according to the WebAssembly specification. This means that it is hypothetically possible for execution within the sandbox to go awry and WebAssembly programs could produce unexpected results. This should not impact hosts executing WebAssembly but does affect the correctness of guest programs. This bug has been patched in Wasmtime version 0.38.2 and cranelift-codegen 0.85.2. There are no known workarounds.
References
Impacted products
Vendor | Product | Version | |
---|---|---|---|
bytecodealliance | cranelift-codegen | * | |
bytecodealliance | wasmtime | * |
{ "configurations": [ { "nodes": [ { "cpeMatch": [ { "criteria": "cpe:2.3:a:bytecodealliance:cranelift-codegen:*:*:*:*:*:rust:*:*", "matchCriteriaId": "1E1303DC-2166-4DCB-8ABE-208849CDD044", "versionEndExcluding": "0.85.1", "vulnerable": true }, { "criteria": "cpe:2.3:a:bytecodealliance:wasmtime:*:*:*:*:*:rust:*:*", "matchCriteriaId": "B9C6651A-233F-40DD-AB1B-1A435F97728B", "versionEndExcluding": "0.38.1", "vulnerable": true } ], "negate": false, "operator": "OR" } ] } ], "cveTags": [], "descriptions": [ { "lang": "en", "value": "Wasmtime is a standalone runtime for WebAssembly. There is a bug in Wasmtime\u0027s code generator, Cranelift, for AArch64 targets where constant divisors can result in incorrect division results at runtime. This affects Wasmtime prior to version 0.38.2 and Cranelift prior to 0.85.2. This issue only affects the AArch64 platform. Other platforms are not affected. The translation rules for constants did not take into account whether sign or zero-extension should happen which resulted in an incorrect value being placed into a register when a division was encountered. The impact of this bug is that programs executing within the WebAssembly sandbox would not behave according to the WebAssembly specification. This means that it is hypothetically possible for execution within the sandbox to go awry and WebAssembly programs could produce unexpected results. This should not impact hosts executing WebAssembly but does affect the correctness of guest programs. This bug has been patched in Wasmtime version 0.38.2 and cranelift-codegen 0.85.2. There are no known workarounds." }, { "lang": "es", "value": "Wasmtime es un tiempo de ejecuci\u00f3n independiente para WebAssembly. Se presenta un error en el generador de c\u00f3digo de Wasmtime, Cranelift, para los objetivos AArch64 donde los divisores constantes pueden resultar en resultados de divisi\u00f3n incorrectos en tiempo de ejecuci\u00f3n. Esto afecta a Wasmtime versiones anteriores a 0.38.2 y a Cranelift versiones anteriores a 0.85.2. Este problema s\u00f3lo afecta a la plataforma AArch64. Las dem\u00e1s plataformas no est\u00e1n afectadas. Las reglas de traducci\u00f3n de las constantes no ten\u00edan en cuenta si el signo o la extensi\u00f3n cero deb\u00edan producirse, lo que resultaba en la colocaci\u00f3n de un valor incorrecto en un registro cuando era encontrada una divisi\u00f3n. El impacto de este bug es que los programas que son ejecutados dentro del sandbox de WebAssembly no son comportados de acuerdo con la especificaci\u00f3n de WebAssembly. Esto significa que es hipot\u00e9ticamente posible que la ejecuci\u00f3n dentro del sandbox sea desviado y los programas WebAssembly puedan producir resultados no esperados. Esto no deber\u00eda afectar a los hosts que ejecutan WebAssembly, pero s\u00ed a la correcci\u00f3n de los programas invitados. Este error ha sido parcheado en Wasmtime versi\u00f3n 0.38.2 y en cranelift-codegen versi\u00f3n 0.85.2. No se presentan mitigaciones conocidas" } ], "id": "CVE-2022-31169", "lastModified": "2024-11-21T07:04:02.800", "metrics": { "cvssMetricV31": [ { "cvssData": { "attackComplexity": "HIGH", "attackVector": "NETWORK", "availabilityImpact": "NONE", "baseScore": 5.9, "baseSeverity": "MEDIUM", "confidentialityImpact": "NONE", "integrityImpact": "HIGH", "privilegesRequired": "NONE", "scope": "UNCHANGED", "userInteraction": "NONE", "vectorString": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N", "version": "3.1" }, "exploitabilityScore": 2.2, "impactScore": 3.6, "source": "security-advisories@github.com", "type": "Secondary" }, { "cvssData": { "attackComplexity": "LOW", "attackVector": "NETWORK", "availabilityImpact": "NONE", "baseScore": 7.5, "baseSeverity": "HIGH", "confidentialityImpact": "NONE", "integrityImpact": "HIGH", "privilegesRequired": "NONE", "scope": "UNCHANGED", "userInteraction": "NONE", "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N", "version": "3.1" }, "exploitabilityScore": 3.9, "impactScore": 3.6, "source": "nvd@nist.gov", "type": "Primary" } ] }, "published": "2022-07-22T04:15:14.463", "references": [ { "source": "security-advisories@github.com", "tags": [ "Patch", "Third Party Advisory" ], "url": "https://github.com/bytecodealliance/wasmtime/commit/2ba4bce5cc719e5a74e571a534424614e62ecc41" }, { "source": "security-advisories@github.com", "tags": [ "Third Party Advisory" ], "url": "https://github.com/bytecodealliance/wasmtime/security/advisories/GHSA-7f6x-jwh5-m9r4" }, { "source": "af854a3a-2127-422b-91ae-364da2661108", "tags": [ "Patch", "Third Party Advisory" ], "url": "https://github.com/bytecodealliance/wasmtime/commit/2ba4bce5cc719e5a74e571a534424614e62ecc41" }, { "source": "af854a3a-2127-422b-91ae-364da2661108", "tags": [ "Third Party Advisory" ], "url": "https://github.com/bytecodealliance/wasmtime/security/advisories/GHSA-7f6x-jwh5-m9r4" } ], "sourceIdentifier": "security-advisories@github.com", "vulnStatus": "Modified", "weaknesses": [ { "description": [ { "lang": "en", "value": "CWE-682" } ], "source": "security-advisories@github.com", "type": "Primary" } ] }
cve-2021-32629
Vulnerability from cvelistv5
Published
2021-05-24 15:35
Modified
2024-08-03 23:25
Severity ?
EPSS score ?
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
Impacted products
Vendor | Product | Version | ||
---|---|---|---|---|
bytecodealliance | wasmtime |
Version: <= 0.73.0 |
{ "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" }
cve-2022-31146
Vulnerability from cvelistv5
Published
2022-07-20 22:30
Modified
2024-08-03 07:11
Severity ?
EPSS score ?
Summary
Wasmtime is a standalone runtime for WebAssembly. There is a bug in the Wasmtime's code generator, Cranelift, where functions using reference types may be incorrectly missing metadata required for runtime garbage collection. This means that if a GC happens at runtime then the GC pass will mistakenly think these functions do not have live references to GC'd values, reclaiming them and deallocating them. The function will then subsequently continue to use the values assuming they had not been GC'd, leading later to a use-after-free. This bug was introduced in the migration to the `regalloc2` register allocator that occurred in the Wasmtime 0.37.0 release on 2022-05-20. This bug has been patched and users should upgrade to Wasmtime version 0.38.2. Mitigations for this issue can be achieved by disabling the reference types proposal by passing `false` to `wasmtime::Config::wasm_reference_types` or downgrading to Wasmtime 0.36.0 or prior.
References
▼ | URL | Tags |
---|---|---|
https://github.com/bytecodealliance/wasmtime/security/advisories/GHSA-5fhj-g3p3-pq9g | x_refsource_CONFIRM | |
https://github.com/WebAssembly/reference-types | x_refsource_MISC | |
https://github.com/bytecodealliance/wasmtime/ | x_refsource_MISC |
Impacted products
Vendor | Product | Version | ||
---|---|---|---|---|
bytecodealliance | wasmtime |
Version: >= 0.37.0, < 0.38.2 Version: >= 0.84.0, < 0.85.2 |
{ "containers": { "adp": [ { "providerMetadata": { "dateUpdated": "2024-08-03T07:11:39.649Z", "orgId": "af854a3a-2127-422b-91ae-364da2661108", "shortName": "CVE" }, "references": [ { "tags": [ "x_refsource_CONFIRM", "x_transferred" ], "url": "https://github.com/bytecodealliance/wasmtime/security/advisories/GHSA-5fhj-g3p3-pq9g" }, { "tags": [ "x_refsource_MISC", "x_transferred" ], "url": "https://github.com/WebAssembly/reference-types" }, { "tags": [ "x_refsource_MISC", "x_transferred" ], "url": "https://github.com/bytecodealliance/wasmtime/" } ], "title": "CVE Program Container" } ], "cna": { "affected": [ { "product": "wasmtime", "vendor": "bytecodealliance", "versions": [ { "status": "affected", "version": "\u003e= 0.37.0, \u003c 0.38.2" }, { "status": "affected", "version": "\u003e= 0.84.0, \u003c 0.85.2" } ] } ], "descriptions": [ { "lang": "en", "value": "Wasmtime is a standalone runtime for WebAssembly. There is a bug in the Wasmtime\u0027s code generator, Cranelift, where functions using reference types may be incorrectly missing metadata required for runtime garbage collection. This means that if a GC happens at runtime then the GC pass will mistakenly think these functions do not have live references to GC\u0027d values, reclaiming them and deallocating them. The function will then subsequently continue to use the values assuming they had not been GC\u0027d, leading later to a use-after-free. This bug was introduced in the migration to the `regalloc2` register allocator that occurred in the Wasmtime 0.37.0 release on 2022-05-20. This bug has been patched and users should upgrade to Wasmtime version 0.38.2. Mitigations for this issue can be achieved by disabling the reference types proposal by passing `false` to `wasmtime::Config::wasm_reference_types` or downgrading to Wasmtime 0.36.0 or prior." } ], "metrics": [ { "cvssV3_1": { "attackComplexity": "HIGH", "attackVector": "NETWORK", "availabilityImpact": "LOW", "baseScore": 6.4, "baseSeverity": "MEDIUM", "confidentialityImpact": "HIGH", "integrityImpact": "LOW", "privilegesRequired": "LOW", "scope": "UNCHANGED", "userInteraction": "NONE", "vectorString": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:L/A:L", "version": "3.1" } } ], "problemTypes": [ { "descriptions": [ { "cweId": "CWE-416", "description": "CWE-416: Use After Free", "lang": "en", "type": "CWE" } ] } ], "providerMetadata": { "dateUpdated": "2022-07-22T03:35:18", "orgId": "a0819718-46f1-4df5-94e2-005712e83aaa", "shortName": "GitHub_M" }, "references": [ { "tags": [ "x_refsource_CONFIRM" ], "url": "https://github.com/bytecodealliance/wasmtime/security/advisories/GHSA-5fhj-g3p3-pq9g" }, { "tags": [ "x_refsource_MISC" ], "url": "https://github.com/WebAssembly/reference-types" }, { "tags": [ "x_refsource_MISC" ], "url": "https://github.com/bytecodealliance/wasmtime/" } ], "source": { "advisory": "GHSA-5fhj-g3p3-pq9g", "discovery": "UNKNOWN" }, "title": "Use After Free in Wasmtime", "x_legacyV4Record": { "CVE_data_meta": { "ASSIGNER": "security-advisories@github.com", "ID": "CVE-2022-31146", "STATE": "PUBLIC", "TITLE": "Use After Free in Wasmtime" }, "affects": { "vendor": { "vendor_data": [ { "product": { "product_data": [ { "product_name": "wasmtime", "version": { "version_data": [ { "platform": "", "version_affected": "", "version_name": "", "version_value": "\u003e= 0.37.0, \u003c 0.38.2" }, { "platform": "", "version_affected": "", "version_name": "", "version_value": "\u003e= 0.84.0, \u003c 0.85.2" } ] } } ] }, "vendor_name": "bytecodealliance" } ] } }, "data_format": "MITRE", "data_type": "CVE", "data_version": "4.0", "description": { "description_data": [ { "lang": "eng", "value": "Wasmtime is a standalone runtime for WebAssembly. There is a bug in the Wasmtime\u0027s code generator, Cranelift, where functions using reference types may be incorrectly missing metadata required for runtime garbage collection. This means that if a GC happens at runtime then the GC pass will mistakenly think these functions do not have live references to GC\u0027d values, reclaiming them and deallocating them. The function will then subsequently continue to use the values assuming they had not been GC\u0027d, leading later to a use-after-free. This bug was introduced in the migration to the `regalloc2` register allocator that occurred in the Wasmtime 0.37.0 release on 2022-05-20. This bug has been patched and users should upgrade to Wasmtime version 0.38.2. Mitigations for this issue can be achieved by disabling the reference types proposal by passing `false` to `wasmtime::Config::wasm_reference_types` or downgrading to Wasmtime 0.36.0 or prior." } ] }, "impact": { "cvss": { "attackComplexity": "HIGH", "attackVector": "NETWORK", "availabilityImpact": "LOW", "baseScore": 6.4, "baseSeverity": "MEDIUM", "confidentialityImpact": "HIGH", "integrityImpact": "LOW", "privilegesRequired": "LOW", "scope": "UNCHANGED", "userInteraction": "NONE", "vectorString": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:L/A:L", "version": "3.1" } }, "problemtype": { "problemtype_data": [ { "description": [ { "lang": "eng", "value": "CWE-416: Use After Free" } ] } ] }, "references": { "reference_data": [ { "name": "https://github.com/bytecodealliance/wasmtime/security/advisories/GHSA-5fhj-g3p3-pq9g", "refsource": "CONFIRM", "url": "https://github.com/bytecodealliance/wasmtime/security/advisories/GHSA-5fhj-g3p3-pq9g" }, { "name": "https://github.com/WebAssembly/reference-types", "refsource": "MISC", "url": "https://github.com/WebAssembly/reference-types" }, { "name": "https://github.com/bytecodealliance/wasmtime/", "refsource": "MISC", "url": "https://github.com/bytecodealliance/wasmtime/" } ] }, "source": { "advisory": "GHSA-5fhj-g3p3-pq9g", "discovery": "UNKNOWN" } } } }, "cveMetadata": { "assignerOrgId": "a0819718-46f1-4df5-94e2-005712e83aaa", "assignerShortName": "GitHub_M", "cveId": "CVE-2022-31146", "datePublished": "2022-07-20T22:30:16", "dateReserved": "2022-05-18T00:00:00", "dateUpdated": "2024-08-03T07:11:39.649Z", "state": "PUBLISHED" }, "dataType": "CVE_RECORD", "dataVersion": "5.1" }
cve-2022-31169
Vulnerability from cvelistv5
Published
2022-07-21 13:50
Modified
2024-08-03 07:11
Severity ?
EPSS score ?
Summary
Wasmtime is a standalone runtime for WebAssembly. There is a bug in Wasmtime's code generator, Cranelift, for AArch64 targets where constant divisors can result in incorrect division results at runtime. This affects Wasmtime prior to version 0.38.2 and Cranelift prior to 0.85.2. This issue only affects the AArch64 platform. Other platforms are not affected. The translation rules for constants did not take into account whether sign or zero-extension should happen which resulted in an incorrect value being placed into a register when a division was encountered. The impact of this bug is that programs executing within the WebAssembly sandbox would not behave according to the WebAssembly specification. This means that it is hypothetically possible for execution within the sandbox to go awry and WebAssembly programs could produce unexpected results. This should not impact hosts executing WebAssembly but does affect the correctness of guest programs. This bug has been patched in Wasmtime version 0.38.2 and cranelift-codegen 0.85.2. There are no known workarounds.
References
▼ | URL | Tags |
---|---|---|
https://github.com/bytecodealliance/wasmtime/security/advisories/GHSA-7f6x-jwh5-m9r4 | x_refsource_CONFIRM | |
https://github.com/bytecodealliance/wasmtime/commit/2ba4bce5cc719e5a74e571a534424614e62ecc41 | x_refsource_MISC |
Impacted products
Vendor | Product | Version | ||
---|---|---|---|---|
bytecodealliance | wasmtime |
Version: < 0.38.2 Version: < 0.85.2 |
{ "containers": { "adp": [ { "providerMetadata": { "dateUpdated": "2024-08-03T07:11:39.608Z", "orgId": "af854a3a-2127-422b-91ae-364da2661108", "shortName": "CVE" }, "references": [ { "tags": [ "x_refsource_CONFIRM", "x_transferred" ], "url": "https://github.com/bytecodealliance/wasmtime/security/advisories/GHSA-7f6x-jwh5-m9r4" }, { "tags": [ "x_refsource_MISC", "x_transferred" ], "url": "https://github.com/bytecodealliance/wasmtime/commit/2ba4bce5cc719e5a74e571a534424614e62ecc41" } ], "title": "CVE Program Container" } ], "cna": { "affected": [ { "product": "wasmtime", "vendor": "bytecodealliance", "versions": [ { "status": "affected", "version": "\u003c 0.38.2" }, { "status": "affected", "version": "\u003c 0.85.2" } ] } ], "descriptions": [ { "lang": "en", "value": "Wasmtime is a standalone runtime for WebAssembly. There is a bug in Wasmtime\u0027s code generator, Cranelift, for AArch64 targets where constant divisors can result in incorrect division results at runtime. This affects Wasmtime prior to version 0.38.2 and Cranelift prior to 0.85.2. This issue only affects the AArch64 platform. Other platforms are not affected. The translation rules for constants did not take into account whether sign or zero-extension should happen which resulted in an incorrect value being placed into a register when a division was encountered. The impact of this bug is that programs executing within the WebAssembly sandbox would not behave according to the WebAssembly specification. This means that it is hypothetically possible for execution within the sandbox to go awry and WebAssembly programs could produce unexpected results. This should not impact hosts executing WebAssembly but does affect the correctness of guest programs. This bug has been patched in Wasmtime version 0.38.2 and cranelift-codegen 0.85.2. There are no known workarounds." } ], "metrics": [ { "cvssV3_1": { "attackComplexity": "HIGH", "attackVector": "NETWORK", "availabilityImpact": "NONE", "baseScore": 5.9, "baseSeverity": "MEDIUM", "confidentialityImpact": "NONE", "integrityImpact": "HIGH", "privilegesRequired": "NONE", "scope": "UNCHANGED", "userInteraction": "NONE", "vectorString": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N", "version": "3.1" } } ], "problemTypes": [ { "descriptions": [ { "cweId": "CWE-682", "description": "CWE-682: Incorrect Calculation", "lang": "en", "type": "CWE" } ] } ], "providerMetadata": { "dateUpdated": "2022-07-21T13:50:11", "orgId": "a0819718-46f1-4df5-94e2-005712e83aaa", "shortName": "GitHub_M" }, "references": [ { "tags": [ "x_refsource_CONFIRM" ], "url": "https://github.com/bytecodealliance/wasmtime/security/advisories/GHSA-7f6x-jwh5-m9r4" }, { "tags": [ "x_refsource_MISC" ], "url": "https://github.com/bytecodealliance/wasmtime/commit/2ba4bce5cc719e5a74e571a534424614e62ecc41" } ], "source": { "advisory": "GHSA-7f6x-jwh5-m9r4", "discovery": "UNKNOWN" }, "title": "Cranelift vulnerable to miscompilation of constant values in division on AArch64", "x_legacyV4Record": { "CVE_data_meta": { "ASSIGNER": "security-advisories@github.com", "ID": "CVE-2022-31169", "STATE": "PUBLIC", "TITLE": "Cranelift vulnerable to miscompilation of constant values in division on AArch64" }, "affects": { "vendor": { "vendor_data": [ { "product": { "product_data": [ { "product_name": "wasmtime", "version": { "version_data": [ { "version_value": "\u003c 0.38.2" }, { "version_value": "\u003c 0.85.2" } ] } } ] }, "vendor_name": "bytecodealliance" } ] } }, "data_format": "MITRE", "data_type": "CVE", "data_version": "4.0", "description": { "description_data": [ { "lang": "eng", "value": "Wasmtime is a standalone runtime for WebAssembly. There is a bug in Wasmtime\u0027s code generator, Cranelift, for AArch64 targets where constant divisors can result in incorrect division results at runtime. This affects Wasmtime prior to version 0.38.2 and Cranelift prior to 0.85.2. This issue only affects the AArch64 platform. Other platforms are not affected. The translation rules for constants did not take into account whether sign or zero-extension should happen which resulted in an incorrect value being placed into a register when a division was encountered. The impact of this bug is that programs executing within the WebAssembly sandbox would not behave according to the WebAssembly specification. This means that it is hypothetically possible for execution within the sandbox to go awry and WebAssembly programs could produce unexpected results. This should not impact hosts executing WebAssembly but does affect the correctness of guest programs. This bug has been patched in Wasmtime version 0.38.2 and cranelift-codegen 0.85.2. There are no known workarounds." } ] }, "impact": { "cvss": { "attackComplexity": "HIGH", "attackVector": "NETWORK", "availabilityImpact": "NONE", "baseScore": 5.9, "baseSeverity": "MEDIUM", "confidentialityImpact": "NONE", "integrityImpact": "HIGH", "privilegesRequired": "NONE", "scope": "UNCHANGED", "userInteraction": "NONE", "vectorString": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N", "version": "3.1" } }, "problemtype": { "problemtype_data": [ { "description": [ { "lang": "eng", "value": "CWE-682: Incorrect Calculation" } ] } ] }, "references": { "reference_data": [ { "name": "https://github.com/bytecodealliance/wasmtime/security/advisories/GHSA-7f6x-jwh5-m9r4", "refsource": "CONFIRM", "url": "https://github.com/bytecodealliance/wasmtime/security/advisories/GHSA-7f6x-jwh5-m9r4" }, { "name": "https://github.com/bytecodealliance/wasmtime/commit/2ba4bce5cc719e5a74e571a534424614e62ecc41", "refsource": "MISC", "url": "https://github.com/bytecodealliance/wasmtime/commit/2ba4bce5cc719e5a74e571a534424614e62ecc41" } ] }, "source": { "advisory": "GHSA-7f6x-jwh5-m9r4", "discovery": "UNKNOWN" } } } }, "cveMetadata": { "assignerOrgId": "a0819718-46f1-4df5-94e2-005712e83aaa", "assignerShortName": "GitHub_M", "cveId": "CVE-2022-31169", "datePublished": "2022-07-21T13:50:11", "dateReserved": "2022-05-18T00:00:00", "dateUpdated": "2024-08-03T07:11:39.608Z", "state": "PUBLISHED" }, "dataType": "CVE_RECORD", "dataVersion": "5.1" }
cve-2023-27477
Vulnerability from cvelistv5
Published
2023-03-08 00:00
Modified
2025-02-25 14:59
Severity ?
EPSS score ?
Summary
wasmtime is a fast and secure runtime for WebAssembly. Wasmtime's code generation backend, Cranelift, has a bug on x86_64 platforms for the WebAssembly `i8x16.select` instruction which will produce the wrong results when the same operand is provided to the instruction and some of the selected indices are greater than 16. There is an off-by-one error in the calculation of the mask to the `pshufb` instruction which causes incorrect results to be returned if lanes are selected from the second vector. This codegen bug has been fixed in Wasmtiem 6.0.1, 5.0.1, and 4.0.1. Users are recommended to upgrade to these updated versions. If upgrading is not an option for you at this time, you can avoid this miscompilation by disabling the Wasm simd proposal. Additionally the bug is only present on x86_64 hosts. Other platforms such as AArch64 and s390x are not affected.
References
Impacted products
Vendor | Product | Version | ||
---|---|---|---|---|
bytecodealliance | wasmtime |
Version: cranelift-codegen: >= 0.88.0, < 0.91.1 Version: cranelift-codegen: >= 0.92.0, < 0.92.1 Version: cranelift-codegen: >= 0.93.0, < 0.93.1 Version: wasmtime: >= 0.37.0, < 4.0.1 Version: wasmtime: >= 5.0.0, < 5.0.1 Version: wasmtime: >= 6.0.0, < 6.0.1 |
{ "containers": { "adp": [ { "providerMetadata": { "dateUpdated": "2024-08-02T12:09:43.514Z", "orgId": "af854a3a-2127-422b-91ae-364da2661108", "shortName": "CVE" }, "references": [ { "tags": [ "x_transferred" ], "url": "https://docs.rs/wasmtime/latest/wasmtime/struct.Config.html#method.wasm_simd" }, { "tags": [ "x_transferred" ], "url": "https://github.com/webassembly/simd" }, { "tags": [ "x_transferred" ], "url": "https://groups.google.com/a/bytecodealliance.org/g/sec-announce/c/Mov-ItrNJsQ" }, { "tags": [ "x_transferred" ], "url": "https://github.com/bytecodealliance/wasmtime/security/advisories/GHSA-xm67-587q-r2vw" }, { "tags": [ "x_transferred" ], "url": "https://github.com/bytecodealliance/wasmtime/commit/5dc2bbccbb363e474d2c9a1b8e38a89a43bbd5d1" } ], "title": "CVE Program Container" }, { "metrics": [ { "other": { "content": { "id": "CVE-2023-27477", "options": [ { "Exploitation": "none" }, { "Automatable": "no" }, { "Technical Impact": "partial" } ], "role": "CISA Coordinator", "timestamp": "2025-02-25T14:30:04.679521Z", "version": "2.0.3" }, "type": "ssvc" } } ], "providerMetadata": { "dateUpdated": "2025-02-25T14:59:59.689Z", "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0", "shortName": "CISA-ADP" }, "title": "CISA ADP Vulnrichment" } ], "cna": { "affected": [ { "product": "wasmtime", "vendor": "bytecodealliance", "versions": [ { "status": "affected", "version": "cranelift-codegen: \u003e= 0.88.0, \u003c 0.91.1" }, { "status": "affected", "version": "cranelift-codegen: \u003e= 0.92.0, \u003c 0.92.1" }, { "status": "affected", "version": "cranelift-codegen: \u003e= 0.93.0, \u003c 0.93.1" }, { "status": "affected", "version": " wasmtime: \u003e= 0.37.0, \u003c 4.0.1" }, { "status": "affected", "version": " wasmtime: \u003e= 5.0.0, \u003c 5.0.1" }, { "status": "affected", "version": " wasmtime: \u003e= 6.0.0, \u003c 6.0.1" } ] } ], "descriptions": [ { "lang": "en", "value": "wasmtime is a fast and secure runtime for WebAssembly. Wasmtime\u0027s code generation backend, Cranelift, has a bug on x86_64 platforms for the WebAssembly `i8x16.select` instruction which will produce the wrong results when the same operand is provided to the instruction and some of the selected indices are greater than 16. There is an off-by-one error in the calculation of the mask to the `pshufb` instruction which causes incorrect results to be returned if lanes are selected from the second vector. This codegen bug has been fixed in Wasmtiem 6.0.1, 5.0.1, and 4.0.1. Users are recommended to upgrade to these updated versions. If upgrading is not an option for you at this time, you can avoid this miscompilation by disabling the Wasm simd proposal. Additionally the bug is only present on x86_64 hosts. Other platforms such as AArch64 and s390x are not affected." } ], "metrics": [ { "cvssV3_1": { "attackComplexity": "HIGH", "attackVector": "NETWORK", "availabilityImpact": "NONE", "baseScore": 3.1, "baseSeverity": "LOW", "confidentialityImpact": "NONE", "integrityImpact": "LOW", "privilegesRequired": "LOW", "scope": "UNCHANGED", "userInteraction": "NONE", "vectorString": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:N/I:L/A:N", "version": "3.1" } } ], "problemTypes": [ { "descriptions": [ { "cweId": "CWE-193", "description": "CWE-193: Off-by-one Error", "lang": "en", "type": "CWE" } ] } ], "providerMetadata": { "dateUpdated": "2023-03-09T00:00:00.000Z", "orgId": "a0819718-46f1-4df5-94e2-005712e83aaa", "shortName": "GitHub_M" }, "references": [ { "url": "https://docs.rs/wasmtime/latest/wasmtime/struct.Config.html#method.wasm_simd" }, { "url": "https://github.com/webassembly/simd" }, { "url": "https://groups.google.com/a/bytecodealliance.org/g/sec-announce/c/Mov-ItrNJsQ" }, { "url": "https://github.com/bytecodealliance/wasmtime/security/advisories/GHSA-xm67-587q-r2vw" }, { "url": "https://github.com/bytecodealliance/wasmtime/commit/5dc2bbccbb363e474d2c9a1b8e38a89a43bbd5d1" } ], "source": { "advisory": "GHSA-xm67-587q-r2vw", "discovery": "UNKNOWN" } } }, "cveMetadata": { "assignerOrgId": "a0819718-46f1-4df5-94e2-005712e83aaa", "assignerShortName": "GitHub_M", "cveId": "CVE-2023-27477", "datePublished": "2023-03-08T00:00:00.000Z", "dateReserved": "2023-03-01T00:00:00.000Z", "dateUpdated": "2025-02-25T14:59:59.689Z", "state": "PUBLISHED" }, "dataType": "CVE_RECORD", "dataVersion": "5.1" }
cve-2022-31104
Vulnerability from cvelistv5
Published
2022-06-27 23:20
Modified
2024-08-03 07:11
Severity ?
EPSS score ?
Summary
Wasmtime is a standalone runtime for WebAssembly. In affected versions wasmtime's implementation of the SIMD proposal for WebAssembly on x86_64 contained two distinct bugs in the instruction lowerings implemented in Cranelift. The aarch64 implementation of the simd proposal is not affected. The bugs were presented in the `i8x16.swizzle` and `select` WebAssembly instructions. The `select` instruction is only affected when the inputs are of `v128` type. The correspondingly affected Cranelift instructions were `swizzle` and `select`. The `swizzle` instruction lowering in Cranelift erroneously overwrote the mask input register which could corrupt a constant value, for example. This means that future uses of the same constant may see a different value than the constant itself. The `select` instruction lowering in Cranelift wasn't correctly implemented for vector types that are 128-bits wide. When the condition was 0 the wrong instruction was used to move the correct input to the output of the instruction meaning that only the low 32 bits were moved and the upper 96 bits of the result were left as whatever the register previously contained (instead of the input being moved from). The `select` instruction worked correctly if the condition was nonzero, however. This bug in Wasmtime's implementation of these instructions on x86_64 represents an incorrect implementation of the specified semantics of these instructions according to the WebAssembly specification. The impact of this is benign for hosts running WebAssembly but represents possible vulnerabilities within the execution of a guest program. For example a WebAssembly program could take unintended branches or materialize incorrect values internally which runs the risk of exposing the program itself to other related vulnerabilities which can occur from miscompilations. We have released Wasmtime 0.38.1 and cranelift-codegen (and other associated cranelift crates) 0.85.1 which contain the corrected implementations of these two instructions in Cranelift. If upgrading is not an option for you at this time, you can avoid the vulnerability by disabling the Wasm simd proposal. Additionally the bug is only present on x86_64 hosts. Other aarch64 hosts are not affected. Note that s390x hosts don't yet implement the simd proposal and are not affected.
References
▼ | URL | Tags |
---|---|---|
https://github.com/bytecodealliance/wasmtime/security/advisories/GHSA-jqwc-c49r-4w2x | x_refsource_CONFIRM | |
https://github.com/bytecodealliance/wasmtime/pull/4317 | x_refsource_MISC | |
https://github.com/bytecodealliance/wasmtime/pull/4318 | x_refsource_MISC | |
https://docs.rs/wasmtime/latest/wasmtime/struct.Config.html#method.wasm_simd | x_refsource_MISC | |
https://github.com/webassembly/simd | x_refsource_MISC | |
https://webassembly.github.io/spec/ | x_refsource_MISC |
Impacted products
Vendor | Product | Version | ||
---|---|---|---|---|
bytecodealliance | wasmtime |
Version: wasmtime: < 0.38.1 Version: cranelift-codegen: < 0.85.0 |
{ "containers": { "adp": [ { "providerMetadata": { "dateUpdated": "2024-08-03T07:11:39.222Z", "orgId": "af854a3a-2127-422b-91ae-364da2661108", "shortName": "CVE" }, "references": [ { "tags": [ "x_refsource_CONFIRM", "x_transferred" ], "url": "https://github.com/bytecodealliance/wasmtime/security/advisories/GHSA-jqwc-c49r-4w2x" }, { "tags": [ "x_refsource_MISC", "x_transferred" ], "url": "https://github.com/bytecodealliance/wasmtime/pull/4317" }, { "tags": [ "x_refsource_MISC", "x_transferred" ], "url": "https://github.com/bytecodealliance/wasmtime/pull/4318" }, { "tags": [ "x_refsource_MISC", "x_transferred" ], "url": "https://docs.rs/wasmtime/latest/wasmtime/struct.Config.html#method.wasm_simd" }, { "tags": [ "x_refsource_MISC", "x_transferred" ], "url": "https://github.com/webassembly/simd" }, { "tags": [ "x_refsource_MISC", "x_transferred" ], "url": "https://webassembly.github.io/spec/" } ], "title": "CVE Program Container" } ], "cna": { "affected": [ { "product": "wasmtime", "vendor": "bytecodealliance", "versions": [ { "status": "affected", "version": " wasmtime: \u003c 0.38.1" }, { "status": "affected", "version": "cranelift-codegen: \u003c 0.85.0" } ] } ], "descriptions": [ { "lang": "en", "value": "Wasmtime is a standalone runtime for WebAssembly. In affected versions wasmtime\u0027s implementation of the SIMD proposal for WebAssembly on x86_64 contained two distinct bugs in the instruction lowerings implemented in Cranelift. The aarch64 implementation of the simd proposal is not affected. The bugs were presented in the `i8x16.swizzle` and `select` WebAssembly instructions. The `select` instruction is only affected when the inputs are of `v128` type. The correspondingly affected Cranelift instructions were `swizzle` and `select`. The `swizzle` instruction lowering in Cranelift erroneously overwrote the mask input register which could corrupt a constant value, for example. This means that future uses of the same constant may see a different value than the constant itself. The `select` instruction lowering in Cranelift wasn\u0027t correctly implemented for vector types that are 128-bits wide. When the condition was 0 the wrong instruction was used to move the correct input to the output of the instruction meaning that only the low 32 bits were moved and the upper 96 bits of the result were left as whatever the register previously contained (instead of the input being moved from). The `select` instruction worked correctly if the condition was nonzero, however. This bug in Wasmtime\u0027s implementation of these instructions on x86_64 represents an incorrect implementation of the specified semantics of these instructions according to the WebAssembly specification. The impact of this is benign for hosts running WebAssembly but represents possible vulnerabilities within the execution of a guest program. For example a WebAssembly program could take unintended branches or materialize incorrect values internally which runs the risk of exposing the program itself to other related vulnerabilities which can occur from miscompilations. We have released Wasmtime 0.38.1 and cranelift-codegen (and other associated cranelift crates) 0.85.1 which contain the corrected implementations of these two instructions in Cranelift. If upgrading is not an option for you at this time, you can avoid the vulnerability by disabling the Wasm simd proposal. Additionally the bug is only present on x86_64 hosts. Other aarch64 hosts are not affected. Note that s390x hosts don\u0027t yet implement the simd proposal and are not affected." } ], "metrics": [ { "cvssV3_1": { "attackComplexity": "HIGH", "attackVector": "NETWORK", "availabilityImpact": "LOW", "baseScore": 4.8, "baseSeverity": "MEDIUM", "confidentialityImpact": "NONE", "integrityImpact": "LOW", "privilegesRequired": "NONE", "scope": "UNCHANGED", "userInteraction": "NONE", "vectorString": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:L", "version": "3.1" } } ], "problemTypes": [ { "descriptions": [ { "cweId": "CWE-682", "description": "CWE-682: Incorrect Calculation", "lang": "en", "type": "CWE" } ] } ], "providerMetadata": { "dateUpdated": "2022-06-27T23:20:13", "orgId": "a0819718-46f1-4df5-94e2-005712e83aaa", "shortName": "GitHub_M" }, "references": [ { "tags": [ "x_refsource_CONFIRM" ], "url": "https://github.com/bytecodealliance/wasmtime/security/advisories/GHSA-jqwc-c49r-4w2x" }, { "tags": [ "x_refsource_MISC" ], "url": "https://github.com/bytecodealliance/wasmtime/pull/4317" }, { "tags": [ "x_refsource_MISC" ], "url": "https://github.com/bytecodealliance/wasmtime/pull/4318" }, { "tags": [ "x_refsource_MISC" ], "url": "https://docs.rs/wasmtime/latest/wasmtime/struct.Config.html#method.wasm_simd" }, { "tags": [ "x_refsource_MISC" ], "url": "https://github.com/webassembly/simd" }, { "tags": [ "x_refsource_MISC" ], "url": "https://webassembly.github.io/spec/" } ], "source": { "advisory": "GHSA-jqwc-c49r-4w2x", "discovery": "UNKNOWN" }, "title": "Miscompilation of `i8x16.swizzle` and `select` with v128 inputs in Wasmtime", "x_legacyV4Record": { "CVE_data_meta": { "ASSIGNER": "security-advisories@github.com", "ID": "CVE-2022-31104", "STATE": "PUBLIC", "TITLE": "Miscompilation of `i8x16.swizzle` and `select` with v128 inputs in Wasmtime" }, "affects": { "vendor": { "vendor_data": [ { "product": { "product_data": [ { "product_name": "wasmtime", "version": { "version_data": [ { "version_value": " wasmtime: \u003c 0.38.1" }, { "version_value": "cranelift-codegen: \u003c 0.85.0" } ] } } ] }, "vendor_name": "bytecodealliance" } ] } }, "data_format": "MITRE", "data_type": "CVE", "data_version": "4.0", "description": { "description_data": [ { "lang": "eng", "value": "Wasmtime is a standalone runtime for WebAssembly. In affected versions wasmtime\u0027s implementation of the SIMD proposal for WebAssembly on x86_64 contained two distinct bugs in the instruction lowerings implemented in Cranelift. The aarch64 implementation of the simd proposal is not affected. The bugs were presented in the `i8x16.swizzle` and `select` WebAssembly instructions. The `select` instruction is only affected when the inputs are of `v128` type. The correspondingly affected Cranelift instructions were `swizzle` and `select`. The `swizzle` instruction lowering in Cranelift erroneously overwrote the mask input register which could corrupt a constant value, for example. This means that future uses of the same constant may see a different value than the constant itself. The `select` instruction lowering in Cranelift wasn\u0027t correctly implemented for vector types that are 128-bits wide. When the condition was 0 the wrong instruction was used to move the correct input to the output of the instruction meaning that only the low 32 bits were moved and the upper 96 bits of the result were left as whatever the register previously contained (instead of the input being moved from). The `select` instruction worked correctly if the condition was nonzero, however. This bug in Wasmtime\u0027s implementation of these instructions on x86_64 represents an incorrect implementation of the specified semantics of these instructions according to the WebAssembly specification. The impact of this is benign for hosts running WebAssembly but represents possible vulnerabilities within the execution of a guest program. For example a WebAssembly program could take unintended branches or materialize incorrect values internally which runs the risk of exposing the program itself to other related vulnerabilities which can occur from miscompilations. We have released Wasmtime 0.38.1 and cranelift-codegen (and other associated cranelift crates) 0.85.1 which contain the corrected implementations of these two instructions in Cranelift. If upgrading is not an option for you at this time, you can avoid the vulnerability by disabling the Wasm simd proposal. Additionally the bug is only present on x86_64 hosts. Other aarch64 hosts are not affected. Note that s390x hosts don\u0027t yet implement the simd proposal and are not affected." } ] }, "impact": { "cvss": { "attackComplexity": "HIGH", "attackVector": "NETWORK", "availabilityImpact": "LOW", "baseScore": 4.8, "baseSeverity": "MEDIUM", "confidentialityImpact": "NONE", "integrityImpact": "LOW", "privilegesRequired": "NONE", "scope": "UNCHANGED", "userInteraction": "NONE", "vectorString": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:L", "version": "3.1" } }, "problemtype": { "problemtype_data": [ { "description": [ { "lang": "eng", "value": "CWE-682: Incorrect Calculation" } ] } ] }, "references": { "reference_data": [ { "name": "https://github.com/bytecodealliance/wasmtime/security/advisories/GHSA-jqwc-c49r-4w2x", "refsource": "CONFIRM", "url": "https://github.com/bytecodealliance/wasmtime/security/advisories/GHSA-jqwc-c49r-4w2x" }, { "name": "https://github.com/bytecodealliance/wasmtime/pull/4317", "refsource": "MISC", "url": "https://github.com/bytecodealliance/wasmtime/pull/4317" }, { "name": "https://github.com/bytecodealliance/wasmtime/pull/4318", "refsource": "MISC", "url": "https://github.com/bytecodealliance/wasmtime/pull/4318" }, { "name": "https://docs.rs/wasmtime/latest/wasmtime/struct.Config.html#method.wasm_simd", "refsource": "MISC", "url": "https://docs.rs/wasmtime/latest/wasmtime/struct.Config.html#method.wasm_simd" }, { "name": "https://github.com/webassembly/simd", "refsource": "MISC", "url": "https://github.com/webassembly/simd" }, { "name": "https://webassembly.github.io/spec/", "refsource": "MISC", "url": "https://webassembly.github.io/spec/" } ] }, "source": { "advisory": "GHSA-jqwc-c49r-4w2x", "discovery": "UNKNOWN" } } } }, "cveMetadata": { "assignerOrgId": "a0819718-46f1-4df5-94e2-005712e83aaa", "assignerShortName": "GitHub_M", "cveId": "CVE-2022-31104", "datePublished": "2022-06-27T23:20:13", "dateReserved": "2022-05-18T00:00:00", "dateUpdated": "2024-08-03T07:11:39.222Z", "state": "PUBLISHED" }, "dataType": "CVE_RECORD", "dataVersion": "5.1" }
cve-2023-26489
Vulnerability from cvelistv5
Published
2023-03-08 19:59
Modified
2025-02-25 14:59
Severity ?
EPSS score ?
Summary
wasmtime is a fast and secure runtime for WebAssembly. In affected versions wasmtime's code generator, Cranelift, has a bug on x86_64 targets where address-mode computation mistakenly would calculate a 35-bit effective address instead of WebAssembly's defined 33-bit effective address. This bug means that, with default codegen settings, a wasm-controlled load/store operation could read/write addresses up to 35 bits away from the base of linear memory. Due to this bug, however, addresses up to `0xffffffff * 8 + 0x7ffffffc = 36507222004 = ~34G` bytes away from the base of linear memory are possible from guest code. This means that the virtual memory 6G away from the base of linear memory up to ~34G away can be read/written by a malicious module. A guest module can, without the knowledge of the embedder, read/write memory in this region. The memory may belong to other WebAssembly instances when using the pooling allocator, for example. Affected embedders are recommended to analyze preexisting wasm modules to see if they're affected by the incorrect codegen rules and possibly correlate that with an anomalous number of traps during historical execution to locate possibly suspicious modules. The specific bug in Cranelift's x86_64 backend is that a WebAssembly address which is left-shifted by a constant amount from 1 to 3 will get folded into x86_64's addressing modes which perform shifts. For example `(i32.load (i32.shl (local.get 0) (i32.const 3)))` loads from the WebAssembly address `$local0 << 3`. When translated to Cranelift the `$local0 << 3` computation, a 32-bit value, is zero-extended to a 64-bit value and then added to the base address of linear memory. Cranelift would generate an instruction of the form `movl (%base, %local0, 8), %dst` which calculates `%base + %local0 << 3`. The bug here, however, is that the address computation happens with 64-bit values, where the `$local0 << 3` computation was supposed to be truncated to a a 32-bit value. This means that `%local0`, which can use up to 32-bits for an address, gets 3 extra bits of address space to be accessible via this `movl` instruction. The fix in Cranelift is to remove the erroneous lowering rules in the backend which handle these zero-extended expression. The above example is then translated to `movl %local0, %temp; shl $3, %temp; movl (%base, %temp), %dst` which correctly truncates the intermediate computation of `%local0 << 3` to 32-bits inside the `%temp` register which is then added to the `%base` value. Wasmtime version 4.0.1, 5.0.1, and 6.0.1 have been released and have all been patched to no longer contain the erroneous lowering rules. While updating Wasmtime is recommended, there are a number of possible workarounds that embedders can employ to mitigate this issue if updating is not possible. Note that none of these workarounds are on-by-default and require explicit configuration: 1. The `Config::static_memory_maximum_size(0)` option can be used to force all accesses to linear memory to be explicitly bounds-checked. This will perform a bounds check separately from the address-mode computation which correctly calculates the effective address of a load/store. Note that this can have a large impact on the execution performance of WebAssembly modules. 2. The `Config::static_memory_guard_size(1 << 36)` option can be used to greatly increase the guard pages placed after linear memory. This will guarantee that memory accesses up-to-34G away are guaranteed to be semantically correct by reserving unmapped memory for the instance. Note that this reserves a very large amount of virtual memory per-instances and can greatly reduce the maximum number of concurrent instances being run. 3. If using a non-x86_64 host is possible, then that will also work around this bug. This bug does not affect Wasmtime's or Cranelift's AArch64 backend, for example.
References
Impacted products
Vendor | Product | Version | ||
---|---|---|---|---|
bytecodealliance | wasmtime |
Version: cranelift-codegen: >= 0.84.0, < 0.91.1 Version: cranelift-codegen: >= 0.92.0, < 0.92.1 Version: cranelift-codegen: >= 0.93.0, < 0.93.1 Version: wasmtime: >= 0.37.0, < 4.0.1 Version: wasmtime: >= 5.0.0, < 5.0.1 Version: wasmtime: >= 6.0.0, < 6.0.1 |
{ "containers": { "adp": [ { "providerMetadata": { "dateUpdated": "2024-08-02T11:53:52.930Z", "orgId": "af854a3a-2127-422b-91ae-364da2661108", "shortName": "CVE" }, "references": [ { "name": "https://github.com/bytecodealliance/wasmtime/security/advisories/GHSA-ff4p-7xrq-q5r8", "tags": [ "x_refsource_CONFIRM", "x_transferred" ], "url": "https://github.com/bytecodealliance/wasmtime/security/advisories/GHSA-ff4p-7xrq-q5r8" }, { "name": "https://github.com/bytecodealliance/wasmtime/commit/63fb30e4b4415455d47b3da5a19d79c12f4f2d1f", "tags": [ "x_refsource_MISC", "x_transferred" ], "url": "https://github.com/bytecodealliance/wasmtime/commit/63fb30e4b4415455d47b3da5a19d79c12f4f2d1f" }, { "name": "https://docs.rs/wasmtime/latest/wasmtime/struct.Config.html#method.static_memory_guard_size", "tags": [ "x_refsource_MISC", "x_transferred" ], "url": "https://docs.rs/wasmtime/latest/wasmtime/struct.Config.html#method.static_memory_guard_size" }, { "name": "https://docs.rs/wasmtime/latest/wasmtime/struct.Config.html#method.static_memory_maximum_size", "tags": [ "x_refsource_MISC", "x_transferred" ], "url": "https://docs.rs/wasmtime/latest/wasmtime/struct.Config.html#method.static_memory_maximum_size" }, { "name": "https://groups.google.com/a/bytecodealliance.org/g/sec-announce/c/Mov-ItrNJsQ", "tags": [ "x_refsource_MISC", "x_transferred" ], "url": "https://groups.google.com/a/bytecodealliance.org/g/sec-announce/c/Mov-ItrNJsQ" } ], "title": "CVE Program Container" }, { "metrics": [ { "other": { "content": { "id": "CVE-2023-26489", "options": [ { "Exploitation": "none" }, { "Automatable": "no" }, { "Technical Impact": "total" } ], "role": "CISA Coordinator", "timestamp": "2025-02-25T14:29:41.194404Z", "version": "2.0.3" }, "type": "ssvc" } } ], "providerMetadata": { "dateUpdated": "2025-02-25T14:59:40.063Z", "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0", "shortName": "CISA-ADP" }, "title": "CISA ADP Vulnrichment" } ], "cna": { "affected": [ { "product": "wasmtime", "vendor": "bytecodealliance", "versions": [ { "status": "affected", "version": "cranelift-codegen: \u003e= 0.84.0, \u003c 0.91.1" }, { "status": "affected", "version": "cranelift-codegen: \u003e= 0.92.0, \u003c 0.92.1" }, { "status": "affected", "version": "cranelift-codegen: \u003e= 0.93.0, \u003c 0.93.1" }, { "status": "affected", "version": " wasmtime: \u003e= 0.37.0, \u003c 4.0.1" }, { "status": "affected", "version": " wasmtime: \u003e= 5.0.0, \u003c 5.0.1" }, { "status": "affected", "version": " wasmtime: \u003e= 6.0.0, \u003c 6.0.1" } ] } ], "descriptions": [ { "lang": "en", "value": "wasmtime is a fast and secure runtime for WebAssembly. In affected versions wasmtime\u0027s code generator, Cranelift, has a bug on x86_64 targets where address-mode computation mistakenly would calculate a 35-bit effective address instead of WebAssembly\u0027s defined 33-bit effective address. This bug means that, with default codegen settings, a wasm-controlled load/store operation could read/write addresses up to 35 bits away from the base of linear memory. Due to this bug, however, addresses up to `0xffffffff * 8 + 0x7ffffffc = 36507222004 = ~34G` bytes away from the base of linear memory are possible from guest code. This means that the virtual memory 6G away from the base of linear memory up to ~34G away can be read/written by a malicious module. A guest module can, without the knowledge of the embedder, read/write memory in this region. The memory may belong to other WebAssembly instances when using the pooling allocator, for example. Affected embedders are recommended to analyze preexisting wasm modules to see if they\u0027re affected by the incorrect codegen rules and possibly correlate that with an anomalous number of traps during historical execution to locate possibly suspicious modules. The specific bug in Cranelift\u0027s x86_64 backend is that a WebAssembly address which is left-shifted by a constant amount from 1 to 3 will get folded into x86_64\u0027s addressing modes which perform shifts. For example `(i32.load (i32.shl (local.get 0) (i32.const 3)))` loads from the WebAssembly address `$local0 \u003c\u003c 3`. When translated to Cranelift the `$local0 \u003c\u003c 3` computation, a 32-bit value, is zero-extended to a 64-bit value and then added to the base address of linear memory. Cranelift would generate an instruction of the form `movl (%base, %local0, 8), %dst` which calculates `%base + %local0 \u003c\u003c 3`. The bug here, however, is that the address computation happens with 64-bit values, where the `$local0 \u003c\u003c 3` computation was supposed to be truncated to a a 32-bit value. This means that `%local0`, which can use up to 32-bits for an address, gets 3 extra bits of address space to be accessible via this `movl` instruction. The fix in Cranelift is to remove the erroneous lowering rules in the backend which handle these zero-extended expression. The above example is then translated to `movl %local0, %temp; shl $3, %temp; movl (%base, %temp), %dst` which correctly truncates the intermediate computation of `%local0 \u003c\u003c 3` to 32-bits inside the `%temp` register which is then added to the `%base` value. Wasmtime version 4.0.1, 5.0.1, and 6.0.1 have been released and have all been patched to no longer contain the erroneous lowering rules. While updating Wasmtime is recommended, there are a number of possible workarounds that embedders can employ to mitigate this issue if updating is not possible. Note that none of these workarounds are on-by-default and require explicit configuration: 1. The `Config::static_memory_maximum_size(0)` option can be used to force all accesses to linear memory to be explicitly bounds-checked. This will perform a bounds check separately from the address-mode computation which correctly calculates the effective address of a load/store. Note that this can have a large impact on the execution performance of WebAssembly modules. 2. The `Config::static_memory_guard_size(1 \u003c\u003c 36)` option can be used to greatly increase the guard pages placed after linear memory. This will guarantee that memory accesses up-to-34G away are guaranteed to be semantically correct by reserving unmapped memory for the instance. Note that this reserves a very large amount of virtual memory per-instances and can greatly reduce the maximum number of concurrent instances being run. 3. If using a non-x86_64 host is possible, then that will also work around this bug. This bug does not affect Wasmtime\u0027s or Cranelift\u0027s AArch64 backend, for example.\n" } ], "metrics": [ { "cvssV3_1": { "attackComplexity": "LOW", "attackVector": "NETWORK", "availabilityImpact": "HIGH", "baseScore": 10, "baseSeverity": "CRITICAL", "confidentialityImpact": "HIGH", "integrityImpact": "HIGH", "privilegesRequired": "LOW", "scope": "CHANGED", "userInteraction": "NONE", "vectorString": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H", "version": "3.1" } } ], "problemTypes": [ { "descriptions": [ { "cweId": "CWE-125", "description": "CWE-125: Out-of-bounds Read", "lang": "en", "type": "CWE" } ] }, { "descriptions": [ { "cweId": "CWE-787", "description": "CWE-787: Out-of-bounds Write", "lang": "en", "type": "CWE" } ] } ], "providerMetadata": { "dateUpdated": "2023-03-08T19:59:57.419Z", "orgId": "a0819718-46f1-4df5-94e2-005712e83aaa", "shortName": "GitHub_M" }, "references": [ { "name": "https://github.com/bytecodealliance/wasmtime/security/advisories/GHSA-ff4p-7xrq-q5r8", "tags": [ "x_refsource_CONFIRM" ], "url": "https://github.com/bytecodealliance/wasmtime/security/advisories/GHSA-ff4p-7xrq-q5r8" }, { "name": "https://github.com/bytecodealliance/wasmtime/commit/63fb30e4b4415455d47b3da5a19d79c12f4f2d1f", "tags": [ "x_refsource_MISC" ], "url": "https://github.com/bytecodealliance/wasmtime/commit/63fb30e4b4415455d47b3da5a19d79c12f4f2d1f" }, { "name": "https://docs.rs/wasmtime/latest/wasmtime/struct.Config.html#method.static_memory_guard_size", "tags": [ "x_refsource_MISC" ], "url": "https://docs.rs/wasmtime/latest/wasmtime/struct.Config.html#method.static_memory_guard_size" }, { "name": "https://docs.rs/wasmtime/latest/wasmtime/struct.Config.html#method.static_memory_maximum_size", "tags": [ "x_refsource_MISC" ], "url": "https://docs.rs/wasmtime/latest/wasmtime/struct.Config.html#method.static_memory_maximum_size" }, { "name": "https://groups.google.com/a/bytecodealliance.org/g/sec-announce/c/Mov-ItrNJsQ", "tags": [ "x_refsource_MISC" ], "url": "https://groups.google.com/a/bytecodealliance.org/g/sec-announce/c/Mov-ItrNJsQ" } ], "source": { "advisory": "GHSA-ff4p-7xrq-q5r8", "discovery": "UNKNOWN" }, "title": "Guest-controlled out-of-bounds read/write on x86_64 in wasmtime" } }, "cveMetadata": { "assignerOrgId": "a0819718-46f1-4df5-94e2-005712e83aaa", "assignerShortName": "GitHub_M", "cveId": "CVE-2023-26489", "datePublished": "2023-03-08T19:59:57.419Z", "dateReserved": "2023-02-23T23:22:58.575Z", "dateUpdated": "2025-02-25T14:59:40.063Z", "state": "PUBLISHED" }, "dataType": "CVE_RECORD", "dataVersion": "5.1" }