I come from a SQL and python background, and writing DDL in SQL has gotten me very accustomed to writing code with commas out front when listing and writing data structures. It makes each line a bullet point that is very easy for the eyes to scan.

Something that feels very similar to me is writing enums and match statements. Is there any reason not to use this formatting? Whenever I do, RustRover (my IDE) tells me I shouldn't and gives me annoying warning lines. I'm sure I can configure it not to, but wanted to make sure I'm not trampling over a real reason to avoid that style. Any thoughts?

ex:

enum Furniture {
Chair
, Table
, Desk
, BedFrame
, Couch
}

match Furniture {
Chair => {}
, Table => {}
, Desk=> {}
, BedFrame=> {}
, Couch=> {}

Not sure if Rustaceans in this sub saw this news earlier this month. But given AI agents are getting very good at escaping sandboxes now, it might be worth your attention to patch Wasmtime.

TL;DR: A typo in a validation check let a malicious WebAssembly guest pass an invalid callback signature, overflow the host’s native stack by up to 16KB, and potentially run arbitrary code on the host. Fixed in Wasmtime 48.0.4 and 49.0.2.

Wasmtime is a WebAssembly runtime written in Rust, built by the Bytecode Alliance (Fastly, Mozilla and others are members). It runs WebAssembly modules and components outside the browser, often as a sandbox for untrusted code.

Wasmtime published a critical security advisory on 2 October, GHSA-32h6-97mm-8q3c, CVSS 9.3. The bug sat in the component model’s handling of async callbacks.

Three checks were missing or wrong:

• The validator in wasmparser (crates/wasmparser/src/validator/component.rs) checked a callback’s signature with this line: if func_ty.params() != [ValType::I32; 3] && func_ty.params() != [ValType::I32] { It used && instead of ||, and it checked params() twice instead of checking results() at all. A callback only failed validation if it matched neither shape, so the result type was never checked.
• Wasmtime recorded the callback’s index without checking its arity or return type itself, trusting the validator to have done it. The host-to-guest trampoline had no bounds check on its parameter and result buffer either.
• The stack space reserved for the callback’s return value was sized for the expected arity, not the actual one.

A guest module can supply a callback with an invalid return type that still passes validation. Wasmtime then writes up to about 16KB of guest-controlled data onto the host’s native stack, which can overwrite a return address.

Vulnerable versions: wasmtime 39.0.0 up to 48.0.4, and 49.0.0 up to 49.0.2. Fixed in 48.0.4 and 49.0.2. A workaround is to disable component-model-async, or to validate components with wasmparser 1.260.0 or later before passing them to Wasmtime.

Link to the original source - https://github.com/bytecodealliance/wasmtime/security/advisories/GHSA-32h6-97mm-8q3c