fix bUuDecodeEx: prevent OOM and memory leak on malformed input#148
Open
fix bUuDecodeEx: prevent OOM and memory leak on malformed input#148
Conversation
bsread was called with INT_MAX as the byte limit, allowing up to 2 GB to accumulate in the output bstring when the UU decode stream failed to signal EOF cleanly on input lacking line terminators. Cap the read at src->slen, which is always a safe upper bound since decoded output is smaller than its encoded input. The same function also leaked the bsUuCtx and its two internal bstrings whenever bsUuDecodePart was not invoked before the stream was closed — in particular when src->slen is zero, causing bsread to return immediately without calling the read function. The self-freeing pattern in bsUuDecodePart was inherently fragile: it freed ctx inside the callback, leaving bsclose to return a dangling pointer that bUuDecodeEx silently discarded. Fix by transferring ownership explicitly: bsUuDecodePart now only frees the stream buffers (ctx->io.dst, ctx->io.src) at EOF and nulls them; bUuDecodeEx always frees the ctx container via bsclose's return value. Since bdestroy(NULL) is a no-op, the exit path handles both the fully-consumed and early-close cases safely. Both bugs were detected by libFuzzer fuzz testing.
|
Minimum allowed coverage is Generated by 🐒 cobertura-action against 359515b |
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
bsread was called with INT_MAX as the byte limit, allowing up to 2 GB to accumulate in the output bstring when the UU decode stream failed to signal EOF cleanly on input lacking line terminators. Cap the read at src->slen, which is always a safe upper bound since decoded output is smaller than its encoded input.
The same function also leaked the bsUuCtx and its two internal bstrings whenever bsUuDecodePart was not invoked before the stream was closed — in particular when src->slen is zero, causing bsread to return immediately without calling the read function. The self-freeing pattern in bsUuDecodePart was inherently fragile: it freed ctx inside the callback, leaving bsclose to return a dangling pointer that bUuDecodeEx silently discarded.
Fix by transferring ownership explicitly: bsUuDecodePart now only frees the stream buffers (ctx->io.dst, ctx->io.src) at EOF and nulls them; bUuDecodeEx always frees the ctx container via bsclose's return value. Since bdestroy(NULL) is a no-op, the exit path handles both the fully-consumed and early-close cases safely.
Both bugs were detected by libFuzzer fuzz testing.