Message marshalling makes use of BytesOrPanic a lot, under the
assumption that it will never panic. This assumption was incorrect, and
specifically crafted handshakes could trigger panics. Rather than just
surgically replacing the usages of BytesOrPanic in paths that could
panic, replace all usages of it with proper error returns in case there
are other ways of triggering panics which we didn't find.
In one specific case, the tree routed by expandLabel, we replace the
usage of BytesOrPanic, but retain a panic. This function already
explicitly panicked elsewhere, and returning an error from it becomes
rather painful because it requires changing a large number of APIs.
The marshalling is unlikely to ever panic, as the inputs are all either
fixed length, or already limited to the sizes required. If it were to
panic, it'd likely only be during development. A close inspection shows
no paths for a user to cause a panic currently.
This patches ends up being rather large, since it requires routing
errors back through functions which previously had no error returns.
Where possible I've tried to use helpers that reduce the verbosity
of frequently repeated stanzas, and to make the diffs as minimal as
Thanks to Marten Seemann for reporting this issue.
Reviewed-by: Julie Qiu <email@example.com>
TryBot-Result: Security TryBots <firstname.lastname@example.org>
Run-TryBot: Roland Shoemaker <email@example.com>
Reviewed-by: Damien Neil <firstname.lastname@example.org>
(cherry picked from commit 0f3a44ad7b41cc89efdfad25278953e17d9c1e04)
Reviewed-by: Tatiana Bradley <email@example.com>
Auto-Submit: Michael Pratt <firstname.lastname@example.org>
Run-TryBot: Michael Pratt <email@example.com>
TryBot-Result: Gopher Robot <firstname.lastname@example.org>
Reviewed-by: Than McIntosh <email@example.com>
@rolandshoemaker requested issue #58001 to be considered for backport to the next 1.19 minor release.
The text was updated successfully, but these errors were encountered: