JavaScriptCore’s WebAssembly FunctionParser stored the function’s type as const TypeDefinition& m_signature — a bare C++ reference that does not retain the referenced object. The parser uses m_signature throughout function/constant-expression parsing (m_signature.as<FunctionSignature>() in parse, parseConstantExpression, parseBody, and the TailCall/TailCallIndirect/TailCallRef paths). The invariant that made the bare reference ‘safe’ was that the TypeDefinition outlives the parser, but that does not hold in all cases: the TypeDefinition can be released while the parser is still running (e.g. during recursive/streaming parsing where the owning type registry or module information drops the last other reference), leaving m_signature dangling. Any later dereference is a use-after-free.

The fix changes the member to Ref<const TypeDefinition> m_signature, so the parser holds its own strong reference for its entire lifetime, and updates every use to m_signature->template is/as<FunctionSignature>().

The restored invariant is that the parser owns a reference to the signature TypeDefinition it parses against, so the object cannot be freed underneath it. This is the same ‘retain the wasm TypeDefinition, don’t alias it’ class as the GC type-retention fixes, but here on the parser’s input signature.

A use-after-free of the wasm function-signature TypeDefinition reachable while parsing a crafted module in the WebContent process. Triggering it requires arranging for the signature to be released mid-parse, and the immediate effect is a crash, though a reclaimed TypeDefinition could enable type confusion in the parser. Confined to WebContent; rated medium.