[From nobody Tue Oct  6 21:51:05 2026
Received: (at submit) by bugs.debian.org; 6 Oct 2026 09:55:16 +0000
X-Spam-Checker-Version: SpamAssassin 4.0.1-bugs.debian.org_2005_01_02
 (2024-03-25) on buxtehude.debian.org
X-Spam-Level: 
X-Spam-Status: No, score=-10.9 required=4.0 tests=BAYES_00,FOURLA,
 FROMDEVELOPER,MD5_SHA1_SUM,NO_RELAYS,XMAILER_REPORTBUG autolearn=ham
 autolearn_force=no version=4.0.1-bugs.debian.org_2005_01_02
X-Spam-Bayes: score:0.0000 Tokens: new, 44; hammy, 150; neutral, 116; spammy,
 0. spammytokens: hammytokens:0.000-+--XDebbugsCc,
 0.000-+--X-Debbugs-Cc, 0.000-+--H*F:U*carnil, 0.000-+--H*Ad:N*Bug,
 0.000-+--HTo:N*Debian
Return-path: &lt;carnil@debian.org&gt;
Received: via submission by buxtehude.debian.org with esmtp (Exim 4.96)
 (envelope-from &lt;carnil@debian.org&gt;) id 1xE1tD-00H1pF-0U
 for submit@bugs.debian.org; Tue, 06 Oct 2026 09:55:16 +0000
Content-Type: text/plain; charset=&quot;us-ascii&quot;
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: Salvatore Bonaccorso &lt;carnil@debian.org&gt;
To: Debian Bug Tracking System &lt;submit@bugs.debian.org&gt;
Subject: wabt: CVE-2026-90648
Message-ID: &lt;179128051102.2801598.11778556508459999141.reportbug@eldamar.lan&gt;
X-Mailer: reportbug 13.2.0+nmu1
Date: Tue, 06 Oct 2026 11:55:11 +0200
Delivered-To: submit@bugs.debian.org

Source: wabt
Version: 1.0.41+dfsg+~cs1.0.39-2
Severity: important
Tags: security upstream
Forwarded: https://github.com/WebAssembly/wabt/issues/2831
X-Debbugs-Cc: carnil@debian.org, Debian Security Team &lt;team@security.debian.org&gt;

Hi,

The following vulnerability was published for wabt.

CVE-2026-90648[0]:
| wasm2c in WebAssembly wabt through 1.0.41 allows sandbox escape in
| some situations that primarily involve 32-bit platforms, aka a
| &quot;table flip&quot; attack. It does not check the return value of calloc()
| in wasm_rt_allocate_funcref_table() (wasm2c/wasm-rt-impl-
| tableops.inc). When the funcref table allocation fails, table-&gt;data
| is left NULL while table-&gt;size keeps the guest-declared element
| count; thus, bounds checks still pass and table element accesses
| resolve to absolute memory addresses (i *
| sizeof(wasm_rt_funcref_t)). This gives arbitrary read and write of
| host process memory and - via table.get, table.set, and
| call_indirect - arbitrary code execution, defeating the isolation
| that wasm2c exists to provide (a full sandbox escape). wasm2c is
| used as an in-process sandboxing boundary by RLBox and WasmBoxC,
| including in Firefox, which compiles the Graphite, Hunspell, Ogg,
| Expat, and Woff2 libraries via wasm2c to contain untrusted font,
| media, and XML input. Therefore, sandboxing in these applications is
| potentially affected. Exploitation requires the funcref table
| allocation to fail, for example under an address-space limit
| (RLIMIT_AS), on 32-bit hosts, with vm.overcommit_memory=2, or under
| memory pressure. On 64-bit Linux with default overcommit the
| allocation succeeds and the defect is not triggered. The wasm2c
| memory allocator aborts on calloc failure in the same runtime; the
| table allocator lacks this abort behavior. This was introduced in
| commit ab9e0b55 (PR #813).


If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities &amp; Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2026-90648
    https://www.cve.org/CVERecord?id=CVE-2026-90648
[1] https://github.com/WebAssembly/wabt/issues/2831
[2] https://github.com/WebAssembly/wabt/issues/2854
[3] https://github.com/WebAssembly/wabt/commit/e197d0b7bd3fe426f5963ae540f4426a1d49e89f

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore
]