Skip to content

Conversation

baylesj
Copy link

@baylesj baylesj commented Aug 8, 2025

This patch fixes a downstream fuzzing crash in Chrome, caused by asserting on input data.

Wherever possible, returning an Error Result is greatly preferred, since crashing on user data may cause unexpected application crashes or potentially other issues.

See related Chromium issue: https://g-issues.chromium.org/issues/433557303

baylesj added 3 commits August 8, 2025 15:48
This patch fixes a downstream fuzzing crash in Chrome, caused
by asserting on input data.

Wherever possible, returning an Error Result is greatly preferred, since
crashing on user data may cause unexpected application crashes or
potentially other issues.

See related Chromium issue: https://g-issues.chromium.org/issues/433557303
@baylesj
Copy link
Author

baylesj commented Aug 8, 2025

I think this fix is also part of a larger scoped discussion around how we want to handle issues with input data. In Chromium, we want the decoder to error whenever there is an issue with user data, instead of crash, which has a negative impact on the user. In this library, it would be ideal if, generally speaking, issues with user data ended up in an error Result, and asserts were limited to developer/logic errors.

@baylesj
Copy link
Author

baylesj commented Aug 19, 2025

@pdeljanov mind taking a look?

Copy link
Owner

@pdeljanov pdeljanov left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice find, let's just adjust the error string!

@baylesj
Copy link
Author

baylesj commented Aug 19, 2025

Applied feedback. Thank you for the review!

@pdeljanov pdeljanov merged commit d74f29c into pdeljanov:dev-0.6 Aug 19, 2025
11 checks passed
@pdeljanov
Copy link
Owner

I think this fix is also part of a larger scoped discussion around how we want to handle issues with input data. In Chromium, we want the decoder to error whenever there is an issue with user data, instead of crash, which has a negative impact on the user. In this library, it would be ideal if, generally speaking, issues with user data ended up in an error Result, and asserts were limited to developer/logic errors.

I agree.

We should always return a decode error. Unwrap should only be used after we pre-validate that it, in-fact, can be unwrapped. In the newer areas of the codebase unwraps usually have a "Safety:" comment/justification associated with them to help auditing, but that's a more recent addition.

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.

2 participants