Skip to content

Conversation

@WorldSEnder
Copy link
Contributor

Read symbol names in the custom linking section without the usual limits::MAX_WASM_STRING_SIZE.

Internal symbols can contain the name of generated closure types and monomorphized generic arguments, leading to very long symbol names. While often not semantically meaningful to an engine, these strings are useful for debugging and not subject to any length restriction when emitted by llvm.

Fixes #2332

read symbol names in the custom linking section without the
usual limits::MAX_WASM_STRING_SIZE.

Internal symbols can contain the name of generated closure types
and monomorphized generic arguments, leading to very long symbol names.
While often not semantically meaningful to an engine, these strings are useful
for debugging and not subject to any length restriction when emitted by llvm.
@WorldSEnder WorldSEnder requested a review from a team as a code owner October 7, 2025 00:29
@WorldSEnder WorldSEnder requested review from fitzgen and removed request for a team October 7, 2025 00:29
@WorldSEnder
Copy link
Contributor Author

There is one more call to read_string in the impl for Comdat<'_> but I'm not too familiar with this section's use and if it might be worth to adjust it in this PR. Let me know.

@alexcrichton
Copy link
Member

Yeah that should be reasonable to change, basically anything in custom sections probably shouldn't be using read_string

@alexcrichton alexcrichton added this pull request to the merge queue Oct 7, 2025
Merged via the queue into bytecodealliance:main with commit 7eae949 Oct 7, 2025
34 checks passed
@WorldSEnder WorldSEnder deleted the long-wasm-linking-str branch October 7, 2025 14:38
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

String size out of bounds in linking section

2 participants