-
Notifications
You must be signed in to change notification settings - Fork 17.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
internal/zstd: Bugs and crashes #63824
Comments
Labeling as |
I attempted to make a fix for this issue that: #63959 |
Change https://go.dev/cl/540055 mentions this issue: |
regeneratedSize that is too small will result in index out-of-bounds behaviour for expanded output slices. regeneratedSize should be greater than or equal to 6 Fixes: golang#63824
regeneratedSize that is too small will result in index out-of-bounds behaviour for expanded output slices. regeneratedSize should be greater than or equal to 6 Fixes: golang#63824
This commit adds an additional safety check to ensure that the `regeneratedSize` is not less than 6. If it's smaller, this would lead to an out-of-bounds error when trying to access the third or fourth stream within our slice during decoding." Fixes: golang#63824
This commit adds an additional safety check to ensure that the `regeneratedSize` is not less than 6. If it's smaller, this would lead to an out-of-bounds error when trying to access the third or fourth stream within our slice during decoding. Fixes: golang#63824
refactor literal decoding into decodeSymbol function. Added output buffer checking to avoid panic caused by too small output buffer. Benchmarking hasn't changed much goos: darwin goarch: amd64 pkg: internal/zstd cpu: Intel(R) Core(TM) i7-9750H CPU @ 2.60GHz │ old.txt │ new.txt │ │ sec/op │ sec/op vs base │ Large-12 7.823m ± 2% 7.854m ± 6% ~ (p=0.247 n=10) │ old.txt │ new.txt │ │ B/s │ B/s vs base │ Large-12 33.17Mi ± 2% 33.04Mi ± 6% ~ (p=0.217 n=10) │ old.txt │ new.txt │ │ B/op │ B/op vs base │ Large-12 73.62Ki ± 4% 74.32Ki ± 3% ~ (p=0.424 n=10) │ old.txt │ new.txt │ │ allocs/op │ allocs/op vs base │ Large-12 0.000 ± 0% 0.000 ± 0% ~ (p=1.000 n=10) ¹ ¹ all samples are equal Fixes: golang#63824
The decompressed size of each stream is equal to (Regenerated_Size+3)/4, except for the last stream, which may be up to 3 bytes smaller, to reach a total decompressed size as specified in Regenerated_Size. Fixes golang#63824
The decompressed size of each stream is equal to (Regenerated_Size+3)/4, except for the last stream, which may be up to 3 bytes smaller, to reach a total decompressed size as specified in Regenerated_Size. Fixes golang#63824
The decompressed size of each stream is equal to (Regenerated_Size+3)/4, except for the last stream, which may be up to 3 bytes smaller, to reach a total decompressed size as specified in Regenerated_Size. Fixes golang#63824
@aimuz Will you be picking up the un-reported corruption as well? |
@klauspost If you suspect there's an underlying problem that hasn't been documented yet, please let me know, and I'll investigate it. |
@aimuz I was thinking of the divergence in output in the "B) Missing error reporting" section. |
@klauspost Can you give me more details? |
@aimuz See section B) of the issue above. There is a zip file with reproducers. |
I'm sorry I left the above information out, thank you, I'll look into it 😀 |
Change https://go.dev/cl/541220 mentions this issue: |
Change https://go.dev/cl/542417 mentions this issue: |
@klauspost All issues have been fixed |
@aimuz If you are up for it, here is another batch: batch2.zip Probably only as few root issues. Seeing unreported: Seeing |
It should be fine as described in the documentation here I created an issue in the zstd repository: facebook/zstd#3821 |
This change enhances the zstd Reader's skipFrame function to validate the new offset when skipping frames in a seekable stream, preventing invalid offsets that could occur previously. A set of "bad" test strings has been added to fuzz_test.go to extend the robustness checks against potential decompression panics. Additionally, a new test named TestReaderBad is introduced in zstd_test.go to verify proper error handling with corrupted input strings. The BenchmarkLarge function has also been refactored for clarity, removing unnecessary timer stops and resets. Updates #63824 Change-Id: Iccd248756ad6348afa1395c7799350d07402868a GitHub-Last-Rev: 63055b9 GitHub-Pull-Request: #64056 Reviewed-on: https://go-review.googlesource.com/c/go/+/541220 Reviewed-by: Bryan Mills <bcmills@google.com> Reviewed-by: David Chase <drchase@google.com> Reviewed-by: Klaus Post <klauspost@gmail.com> Auto-Submit: Bryan Mills <bcmills@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
What version of Go are you using (
go version
)?Go
tip
, self compiled.Does this issue reproduce with the latest release?
Yes.
What did you do?
Run some fuzz tests against the internal zstd package.
What did you expect to see?
No output.
What did you see instead?
A) Crash
With the following input, the internal/zstd decompressor can fail. To reproduce:
Add src/internal/zstd/testdata/fuzz/FuzzReader/e4f4dab13d374c2d with the following content:
go test fuzz v1
[]byte("(\xb5/\xfd00\xec\x00\x00&@\x05\x05A7002\x02\x00\x02\x00\x02\x0000000000000000")
This produces the following crash:
Checking that out1+out2+out3 are in bounds fixes the issue, but it seems a bit expensive.
B) Missing error reporting
The following inputs does not report expected problems:
zstd-internal-divergences.zip
Input and various outputs are reported as:
go:
Error reported byinternal/zstd
.klaus
: Error reported by https://github.com/klauspost/compress/zstdzstd.exe
: Error reported from Zstandard CLI (64-bit) v1.5.4Sorry for not having the time to dig into these right now, but I thought it would be the best to get them reported.
The text was updated successfully, but these errors were encountered: