implement WASM plugin #19

Hexilee · 2021-10-15T02:48:03Z

Signed-off-by: xixi [email protected]

Signed-off-by: xixi <[email protected]>

Cargo.lock

Signed-off-by: xixi <[email protected]>

sonatype-lift · 2021-10-19T06:57:51Z

Cargo.lock

@@ -1201,13 +1605,13 @@ dependencies = [

 [[package]]
 name = "rs-tproxy-controller"


Critical OSS Vulnerability:

pkg:cargo/[email protected]

9 Critical, 3 Severe, 0 Moderate, 0 Unknown vulnerabilities have been found across 10 dependencies

Components

pkg:cargo/[email protected]

CRITICAL Vulnerabilities (1)

[CVE-2021-32810] crossbeam-deque is a package of work-stealing deques for building task scheduler...

crossbeam-deque is a package of work-stealing deques for building task schedulers when programming in Rust. In versions prior to 0.7.4 and 0.8.0, the result of the race condition is that one or more tasks in the worker queue can be popped twice instead of other tasks that are forgotten and never popped. If tasks are allocated on the heap, this can cause double free and a memory leak. If not, this still can cause a logical bug. Crates using Stealer::steal, Stealer::steal_batch, or Stealer::steal_batch_and_pop are affected by this issue. This has been fixed in crossbeam-deque 0.8.1 and 0.7.4.

CVSS Score: 9.8

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

pkg:cargo/[email protected]

CRITICAL Vulnerabilities (1)

[CVE-2021-32629] Cranelift is an open-source code generator maintained by Bytecode Alliance. It t...

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

CVSS Score: 8.8

CVSS Vector: CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H

pkg:cargo/[email protected]

CRITICAL Vulnerabilities (1)

[CVE-2021-32714] hyper is an HTTP library for Rust. In versions prior to 0.14.10, hyper's HTTP se...

hyper is an HTTP library for Rust. In versions prior to 0.14.10, hyper's HTTP server and client code had a flaw that could trigger an integer overflow when decoding chunk sizes that are too big. This allows possible data loss, or if combined with an upstream HTTP proxy that allows chunk sizes larger than hyper does, can result in "request smuggling" or "desync attacks." The vulnerability is patched in version 0.14.10. Two possible workarounds exist. One may reject requests manually that contain a Transfer-Encoding header or ensure any upstream proxy rejects Transfer-Encoding chunk sizes greater than what fits in 64-bit unsigned integers.

CVSS Score: 9.1

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

SEVERE Vulnerabilities (1)

[CVE-2021-32715] hyper is an HTTP library for rust. hyper's HTTP/1 server code had a flaw that in...

hyper is an HTTP library for rust. hyper's HTTP/1 server code had a flaw that incorrectly parses and accepts requests with a Content-Length header with a prefixed plus sign, when it should have been rejected as illegal. This combined with an upstream HTTP proxy that doesn't parse such Content-Length headers, but forwards them, can result in "request smuggling" or "desync attacks". The flaw exists in all prior versions of hyper prior to 0.14.10, if built with rustc v1.5.0 or newer. The vulnerability is patched in hyper version 0.14.10. Two workarounds exist: One may reject requests manually that contain a plus sign prefix in the Content-Length header or ensure any upstream proxy handles Content-Length headers with a plus sign prefix.

CVSS Score: 5.3

CVSS Vector: CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N

pkg:cargo/[email protected]

CRITICAL Vulnerabilities (1)

CWE-119: Improper Restriction of Operations within the Bounds of a Memory Buffer

The software performs operations on a memory buffer, but it can read from or write to a memory location that is outside of the intended boundary of the buffer.

CVSS Score: 8.6

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

CWE: CWE-119

SEVERE Vulnerabilities (1)

[CVE-2021-26307] An issue was discovered in the raw-cpuid crate before 9.0.0 for Rust. It allows ...

An issue was discovered in the raw-cpuid crate before 9.0.0 for Rust. It allows __cpuid_count() calls even if the processor does not support the CPUID instruction, which is unsound and causes a deterministic crash.

CVSS Score: 5.5

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

pkg:cargo/[email protected]

CRITICAL Vulnerabilities (1)

[CVE-2021-32629] Cranelift is an open-source code generator maintained by Bytecode Alliance. It t...

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

CVSS Score: 8.8

CVSS Vector: CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H

pkg:cargo/[email protected]

CRITICAL Vulnerabilities (1)

[CVE-2021-32629] Cranelift is an open-source code generator maintained by Bytecode Alliance. It t...

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

CVSS Score: 8.8

CVSS Vector: CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H

pkg:cargo/[email protected]

CRITICAL Vulnerabilities (1)

CWE-119: Improper Restriction of Operations within the Bounds of a Memory Buffer

The software performs operations on a memory buffer, but it can read from or write to a memory location that is outside of the intended boundary of the buffer.

CVSS Score: 8.6

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

CWE: CWE-119

pkg:cargo/[email protected]

CRITICAL Vulnerabilities (1)

[CVE-2021-32629] Cranelift is an open-source code generator maintained by Bytecode Alliance. It t...

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

CVSS Score: 8.8

CVSS Vector: CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H

pkg:cargo/[email protected]

SEVERE Vulnerabilities (1)

[CVE-2020-35914] An issue was discovered in the lock_api crate before 0.4.2 for Rust. A data race...

An issue was discovered in the lock_api crate before 0.4.2 for Rust. A data race can occur because of RwLockWriteGuard unsoundness.

CVSS Score: 4.7

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

pkg:cargo/[email protected]

CRITICAL Vulnerabilities (1)

[CVE-2021-32629] Cranelift is an open-source code generator maintained by Bytecode Alliance. It t...

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

CVSS Score: 8.8

CVSS Vector: CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H

(at-me [in a reply](https://help.sonatype.com/lift/talking-to-lift) with `help` or `ignore`)

sonatype-lift · 2021-10-19T06:57:52Z

Cargo.toml


 [dependencies]
+rs-tproxy-proxy = { path = "./rs-tproxy-proxy" }
+rs-tproxy-controller = { path = "./rs-tproxy-controller" }


Critical OSS Vulnerability:

pkg:cargo/[email protected]

9 Critical, 3 Severe, 0 Moderate, 0 Unknown vulnerabilities have been found across 10 dependencies

Components

pkg:cargo/[email protected]

CRITICAL Vulnerabilities (1)

[CVE-2021-32810] crossbeam-deque is a package of work-stealing deques for building task scheduler...

crossbeam-deque is a package of work-stealing deques for building task schedulers when programming in Rust. In versions prior to 0.7.4 and 0.8.0, the result of the race condition is that one or more tasks in the worker queue can be popped twice instead of other tasks that are forgotten and never popped. If tasks are allocated on the heap, this can cause double free and a memory leak. If not, this still can cause a logical bug. Crates using Stealer::steal, Stealer::steal_batch, or Stealer::steal_batch_and_pop are affected by this issue. This has been fixed in crossbeam-deque 0.8.1 and 0.7.4.

CVSS Score: 9.8

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

pkg:cargo/[email protected]

CRITICAL Vulnerabilities (1)

[CVE-2021-32629] Cranelift is an open-source code generator maintained by Bytecode Alliance. It t...

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

CVSS Score: 8.8

CVSS Vector: CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H

pkg:cargo/[email protected]

CRITICAL Vulnerabilities (1)

[CVE-2021-32714] hyper is an HTTP library for Rust. In versions prior to 0.14.10, hyper's HTTP se...

hyper is an HTTP library for Rust. In versions prior to 0.14.10, hyper's HTTP server and client code had a flaw that could trigger an integer overflow when decoding chunk sizes that are too big. This allows possible data loss, or if combined with an upstream HTTP proxy that allows chunk sizes larger than hyper does, can result in "request smuggling" or "desync attacks." The vulnerability is patched in version 0.14.10. Two possible workarounds exist. One may reject requests manually that contain a Transfer-Encoding header or ensure any upstream proxy rejects Transfer-Encoding chunk sizes greater than what fits in 64-bit unsigned integers.

CVSS Score: 9.1

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

SEVERE Vulnerabilities (1)

[CVE-2021-32715] hyper is an HTTP library for rust. hyper's HTTP/1 server code had a flaw that in...

hyper is an HTTP library for rust. hyper's HTTP/1 server code had a flaw that incorrectly parses and accepts requests with a Content-Length header with a prefixed plus sign, when it should have been rejected as illegal. This combined with an upstream HTTP proxy that doesn't parse such Content-Length headers, but forwards them, can result in "request smuggling" or "desync attacks". The flaw exists in all prior versions of hyper prior to 0.14.10, if built with rustc v1.5.0 or newer. The vulnerability is patched in hyper version 0.14.10. Two workarounds exist: One may reject requests manually that contain a plus sign prefix in the Content-Length header or ensure any upstream proxy handles Content-Length headers with a plus sign prefix.

CVSS Score: 5.3

CVSS Vector: CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N

pkg:cargo/[email protected]

CRITICAL Vulnerabilities (1)

CWE-119: Improper Restriction of Operations within the Bounds of a Memory Buffer

The software performs operations on a memory buffer, but it can read from or write to a memory location that is outside of the intended boundary of the buffer.

CVSS Score: 8.6

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

CWE: CWE-119

SEVERE Vulnerabilities (1)

[CVE-2021-26307] An issue was discovered in the raw-cpuid crate before 9.0.0 for Rust. It allows ...

An issue was discovered in the raw-cpuid crate before 9.0.0 for Rust. It allows __cpuid_count() calls even if the processor does not support the CPUID instruction, which is unsound and causes a deterministic crash.

CVSS Score: 5.5

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

pkg:cargo/[email protected]

CRITICAL Vulnerabilities (1)

[CVE-2021-32629] Cranelift is an open-source code generator maintained by Bytecode Alliance. It t...

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

CVSS Score: 8.8

CVSS Vector: CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H

pkg:cargo/[email protected]

CRITICAL Vulnerabilities (1)

[CVE-2021-32629] Cranelift is an open-source code generator maintained by Bytecode Alliance. It t...

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

CVSS Score: 8.8

CVSS Vector: CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H

pkg:cargo/[email protected]

CRITICAL Vulnerabilities (1)

CWE-119: Improper Restriction of Operations within the Bounds of a Memory Buffer

The software performs operations on a memory buffer, but it can read from or write to a memory location that is outside of the intended boundary of the buffer.

CVSS Score: 8.6

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

CWE: CWE-119

pkg:cargo/[email protected]

CRITICAL Vulnerabilities (1)

[CVE-2021-32629] Cranelift is an open-source code generator maintained by Bytecode Alliance. It t...

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

CVSS Score: 8.8

CVSS Vector: CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H

pkg:cargo/[email protected]

SEVERE Vulnerabilities (1)

[CVE-2020-35914] An issue was discovered in the lock_api crate before 0.4.2 for Rust. A data race...

An issue was discovered in the lock_api crate before 0.4.2 for Rust. A data race can occur because of RwLockWriteGuard unsoundness.

CVSS Score: 4.7

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

pkg:cargo/[email protected]

CRITICAL Vulnerabilities (1)

[CVE-2021-32629] Cranelift is an open-source code generator maintained by Bytecode Alliance. It t...

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

CVSS Score: 8.8

CVSS Vector: CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H

(at-me [in a reply](https://help.sonatype.com/lift/talking-to-lift) with `help` or `ignore`)

Signed-off-by: xixi <[email protected]>

Andrewmatilde

Fatal : if user terminate while setting network , the clear bridge will not work.

Andrewmatilde · 2021-11-01T06:00:27Z

rs-tproxy-controller/src/proxy/controller.rs

@@ -0,0 +1,91 @@
+use std::future::Future;


Since functions in this file only work for config transaction , I think rename it to names such as 'config server' or ... is better.

Andrewmatilde · 2021-11-01T06:10:29Z

rs-tproxy-controller/src/proxy/exec.rs

-            };
-            Ok(())
-        }));
+        tokio::time::sleep(std::time::Duration::from_secs(1)).await;


Why sleep here?

Wait for the server to start.

I think this may be a risk position.

What risks?

Andrewmatilde · 2021-11-01T06:51:36Z

rs-tproxy-controller/src/proxy/exec.rs

-            self.opt = new.opt;
-            self.sender = new.sender.take();
-            self.rx = new.rx.take();
+            self.start(config).await?;


Miss clear_bridge here.

Andrewmatilde · 2021-11-01T07:32:31Z

rs-tproxy-proxy/src/controller.rs

+    }
+}
+
+impl PluginMap {


I think move PluginMap into Plugin mod may be better .

Andrewmatilde · 2021-11-01T07:37:25Z

example.yaml:
proxy_ports: [80]
plugin_path: /aaa.wasm
rules:

target: Request
selector:
method: GET
actions:
delay: 5s

What's wrong?

Hexilee · 2021-11-02T06:23:42Z

example.yaml: proxy_ports: [80] plugin_path: /aaa.wasm rules:

target: Request
selector:
method: GET
actions:
delay: 5s

What's wrong?

plugin_path should be a directory, which is similar to PATH and GOPATH. Now rs-tproxy will load all xxx.wasm files in plugin_path, and you should add plugin: xxx in rules to use the plugins.

Andrewmatilde · 2021-11-02T06:32:33Z

example.yaml: proxy_ports: [80] plugin_path: /aaa.wasm rules:

target: Request
selector:
method: GET
actions:
delay: 5s

What's wrong?

plugin_path should be a directory, which is similar to PATH and GOPATH. Now rs-tproxy will load all xxx.wasm files in plugin_path, and you should add plugin: xxx in rules to use the plugins.

OK, thx. Add more error message may be better.

Hexilee · 2021-11-02T06:34:38Z

example.yaml: proxy_ports: [80] plugin_path: /aaa.wasm rules:

target: Request
selector:
method: GET
actions:
delay: 5s

What's wrong?

plugin_path should be a directory, which is similar to PATH and GOPATH. Now rs-tproxy will load all xxx.wasm files in plugin_path, and you should add plugin: xxx in rules to use the plugins.

OK, thx. Add more error message may be better.

Well, I will check the path at starting.

Andrewmatilde · 2021-12-21T15:23:11Z

rs-tproxy-controller/src/proxy/exec.rs

-        }));
+        tokio::time::sleep(std::time::Duration::from_secs(1)).await;
+        send_config(&self.opt.ipc_path, &config).await?;
+        self.task = Some(Task::start(async move { Ok(process.wait().await?) }));


When to del the subprocess?

Andrewmatilde · 2021-12-21T15:29:18Z

rs-tproxy-proxy/src/controller.rs

+    }
+}
+
+impl CtrlService {


I may have some misunderstanding but whether both the CtrlServer & ProxyGuard is necessary ?

Andrewmatilde · 2021-12-21T15:35:39Z

rs-tproxy-proxy/src/proxy/http/server.rs

        let addr = SocketAddr::from(([0, 0, 0, 0], self.config.proxy_port));
        let listener = TcpListener::bind(addr)?;
-        tracing::info!(target : "Proxy", "Listening");


I think keep the shutdown receiver is better.

Hexilee added 18 commits October 12, 2021 00:28

run format; add plugin config

da7f09c

Signed-off-by: xixi <[email protected]>

add plugin mod in proxy handler

b4986a1

Signed-off-by: xixi <[email protected]>

apply plugins in proxy

86cecd2

Signed-off-by: xixi <[email protected]>

add wasm plugin example

30f5628

Signed-off-by: xixi <[email protected]>

add unit test for plugin handle_response

612bc5b

Signed-off-by: xixi <[email protected]>

plugin pass basic test

6aff733

Signed-off-by: xixi <[email protected]>

add logger

80c620a

Signed-off-by: xixi <[email protected]>

logger works

332423e

Signed-off-by: xixi <[email protected]>

add macro register_response_handler and register_request_handler

034bf05

Signed-off-by: xixi <[email protected]>

make macro easier to use

eaa9037

Signed-off-by: xixi <[email protected]>

update docs about plugin

12e2b02

Signed-off-by: xixi <[email protected]>

precompile plugin

f6795e6

Signed-off-by: xixi <[email protected]>

remove time calculate code in plugin test

5796832

Signed-off-by: xixi <[email protected]>

change toolchain to nightly

085fe9b

Signed-off-by: xixi <[email protected]>

use json instead of bincode in uds service

8a9f57a

Signed-off-by: xixi <[email protected]>

fix logs

58f79e0

Signed-off-by: xixi <[email protected]>

fix dependencies

92520d6

Signed-off-by: xixi <[email protected]>

plugin pass mannel test

8cedb11

Signed-off-by: xixi <[email protected]>

sonatype-lift bot reviewed Oct 15, 2021

View reviewed changes

Cargo.lock Show resolved Hide resolved

Hexilee added 9 commits October 15, 2021 19:08

update toolchain in stable test

5c4d50d

Signed-off-by: xixi <[email protected]>

fix clippy

282f9ff

Signed-off-by: xixi <[email protected]>

add target wasm32-unknown-unknown in stable test

6b6ddf6

Signed-off-by: xixi <[email protected]>

fix wrong YAML

321b700

Signed-off-by: xixi <[email protected]>

add uds_server in proxy

cbd58f0

Signed-off-by: xixi <[email protected]>

merge from master

1d4e58f

Signed-off-by: xixi <[email protected]>

refactor rs-tproxy-proxy

2a10471

Signed-off-by: xixi <[email protected]>

fix lint

3a11d76

Signed-off-by: xixi <[email protected]>

add client for contoller

b382858

Signed-off-by: xixi <[email protected]>

Hexilee requested review from Andrewmatilde and YangKeao October 19, 2021 06:55

sonatype-lift bot reviewed Oct 19, 2021

View reviewed changes

Hexilee added 8 commits October 19, 2021 22:18

successfully to cache plugin

8ccc511

Signed-off-by: xixi <[email protected]>

fix integrations test

51da97d

Signed-off-by: xixi <[email protected]>

refactor cargo modules style to 2018 edition

7b4bd17

Signed-off-by: xixi <[email protected]>

update config-examples

1c9458a

Signed-off-by: xixi <[email protected]>

update crates version

560950b

Signed-off-by: xixi <[email protected]>

update Carago.lock

347156d

Signed-off-by: xixi <[email protected]>

fix integration test

48670e0

Signed-off-by: xixi <[email protected]>

merge from master

430029a

Signed-off-by: xixi <[email protected]>

Andrewmatilde reviewed Nov 1, 2021

View reviewed changes

rs-tproxy-proxy/src/controller.rs

}

}

impl PluginMap {

Copy link

Member

Andrewmatilde Nov 1, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think move PluginMap into Plugin mod may be better .

Hexilee mentioned this pull request Nov 17, 2021

chaos-tproxy process not found after chaos-daemon restarting chaos-mesh/chaos-mesh#2536

Closed

Hexilee mentioned this pull request Dec 8, 2021

Issue about gRPC chaos chaos-mesh/chaos-mesh#2611

Closed

Andrewmatilde reviewed Dec 21, 2021

View reviewed changes

Hexilee mentioned this pull request Mar 25, 2022

Feature Tracking: HTTPChaos chaos-mesh/chaos-mesh#3062

Open

10 tasks

		@@ -1201,13 +1605,13 @@ dependencies = [

		[[package]]
		name = "rs-tproxy-controller"

implement WASM plugin #19

Are you sure you want to change the base?

implement WASM plugin #19

Conversation

Hexilee commented Oct 15, 2021

sonatype-lift bot Oct 19, 2021

Choose a reason for hiding this comment

pkg:cargo/[email protected]

[CVE-2021-32810] crossbeam-deque is a package of work-stealing deques for building task scheduler...

[CVE-2021-32629] Cranelift is an open-source code generator maintained by Bytecode Alliance. It t...

[CVE-2021-32714] hyper is an HTTP library for Rust. In versions prior to 0.14.10, hyper's HTTP se...

[CVE-2021-32715] hyper is an HTTP library for rust. hyper's HTTP/1 server code had a flaw that in...

CWE-119: Improper Restriction of Operations within the Bounds of a Memory Buffer

[CVE-2021-26307] An issue was discovered in the raw-cpuid crate before 9.0.0 for Rust. It allows ...

[CVE-2021-32629] Cranelift is an open-source code generator maintained by Bytecode Alliance. It t...

[CVE-2021-32629] Cranelift is an open-source code generator maintained by Bytecode Alliance. It t...

CWE-119: Improper Restriction of Operations within the Bounds of a Memory Buffer

[CVE-2021-32629] Cranelift is an open-source code generator maintained by Bytecode Alliance. It t...

[CVE-2020-35914] An issue was discovered in the lock_api crate before 0.4.2 for Rust. A data race...

[CVE-2021-32629] Cranelift is an open-source code generator maintained by Bytecode Alliance. It t...

sonatype-lift bot Oct 19, 2021

Choose a reason for hiding this comment

pkg:cargo/[email protected]

[CVE-2021-32810] crossbeam-deque is a package of work-stealing deques for building task scheduler...

[CVE-2021-32629] Cranelift is an open-source code generator maintained by Bytecode Alliance. It t...

[CVE-2021-32714] hyper is an HTTP library for Rust. In versions prior to 0.14.10, hyper's HTTP se...

[CVE-2021-32715] hyper is an HTTP library for rust. hyper's HTTP/1 server code had a flaw that in...

CWE-119: Improper Restriction of Operations within the Bounds of a Memory Buffer

[CVE-2021-26307] An issue was discovered in the raw-cpuid crate before 9.0.0 for Rust. It allows ...

[CVE-2021-32629] Cranelift is an open-source code generator maintained by Bytecode Alliance. It t...

[CVE-2021-32629] Cranelift is an open-source code generator maintained by Bytecode Alliance. It t...

CWE-119: Improper Restriction of Operations within the Bounds of a Memory Buffer

[CVE-2021-32629] Cranelift is an open-source code generator maintained by Bytecode Alliance. It t...

[CVE-2020-35914] An issue was discovered in the lock_api crate before 0.4.2 for Rust. A data race...

[CVE-2021-32629] Cranelift is an open-source code generator maintained by Bytecode Alliance. It t...

Andrewmatilde left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Andrewmatilde commented Nov 1, 2021 • edited Loading

Hexilee commented Nov 2, 2021 • edited Loading

Andrewmatilde commented Nov 2, 2021

Hexilee commented Nov 2, 2021

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Andrewmatilde commented Nov 1, 2021 •

edited

Loading

Hexilee commented Nov 2, 2021 •

edited

Loading