[JSC] Do not truncate table64 maximum size to uint32_t

A correct import check on a number that wrapped before it ever arrived.

Component: JSC WebAssembly | b91045c

TableInformation is the struct that carries a table's declared bounds through validation, linking, and JIT compilation. Under table64 a table can declare a 64-bit maximum size, but the struct stored maximum as std::optional<uint32_t> — so any value above 2^32 was narrowed at the point of storage, not merely at one call site. Two consumers matter: when a module declares initial == maximum for an imported table, JSC's BBQ/OMG tiers treat it as fixed-size and bake the length into compiled code as a constant, skipping runtime bounds checks; and link-time import checks compare an imported table's actual maximum against the module's declared maximum.

Source/JavaScriptCore/wasm/WasmFormat.h

-    TableInformation(uint32_t initial, std::optional<uint32_t> maximum, ...)
+    TableInformation(uint32_t initial, std::optional<uint64_t> maximum, ...)
-    std::optional<uint32_t> maximum() const { return m_maximum; }
+    std::optional<uint64_t> maximum() const { return m_maximum; }
 private:
-    std::optional<uint32_t> m_maximum;
+    std::optional<uint64_t> m_maximum;

Source/JavaScriptCore/wasm/js/WebAssemblyModuleRecord.cpp

-            if (std::optional<uint32_t> expectedMaximum = moduleInformation.tables[import.kindIndex].maximum()) {
-                std::optional<uint32_t> actualMaximum = table->maximum();
+            if (std::optional<uint64_t> expectedMaximum = moduleInformation.tables[import.kindIndex].maximum()) {
+                std::optional<uint64_t> actualMaximum = table->maximum();
                 if (!actualMaximum)
                     return exception(...);
                 if (*actualMaximum > *expectedMaximum)

The fix widens the stored and plumbed type to uint64_t throughout WasmFormat.h, JSWebAssemblyTable, WebAssemblyModuleConstructor, and WebAssemblyModuleRecord, covering all three consumer classes at once: link-time import compatibility checks, module-declared (non-imported) table growth, and JS API type reflection.

Significance

The truncation had two distinct failure modes. A table64 whose true maximum exceeds 2^32 could wrap down and violate Wasm::Table's maximum-≥-length invariant, leaving a standalone table unable to grow — or, worse, a wrapped-down maximum could falsely satisfy a fixed-size (initial == maximum) import check, then grow at runtime underneath BBQ/OMG code that folded the table's length into a compile-time constant. A real maximum just above 2^32 such as 4294967301 is enough to reach either path.

Audit directions

This is a truncate-then-trust bug: a 64-bit bound was narrowed at the point it was stored, and the wrong value then propagated into both a JIT compile-time-constant assumption and a link-time compatibility check. Narrow: audit other spots in the wasm pipeline that carry 64-bit table or memory bounds through structures or APIs still typed 32-bit — grow paths and the other memory64/table64 reflection surfaces are the direct siblings. Wider: the more dangerous half of this bug is the second-order one, so enumerate every other place a tier assumes a checked bound stays constant after link and confirm the bound it folded was never narrowed upstream; a correct check on a truncated input is indistinguishable from a correct check at the call site. Widest: storage-point narrowing defeats call-site auditing entirely, because every consumer looks correct in isolation — the review tell is a struct member whose declared width is narrower than the width of the accessor's callers, which no single-file diff review will surface.