compress/gzip: detect truncated headers with certain flags set #51417
Labels
Milestone
Comments
philjb
added a commit
to philjb/go
that referenced
this issue
Mar 1, 2022
For cases where rfc 1952 requires a field, the code returns the error 'unexpected EOF' except in two places: for the FNAME flag or the FCOMMENT flag. These flags expect a null-terminated string and `readString()` may return an EOF if the Reader is truncated before a null byte is found. For consistency with parsing other parts of the header, this is converted to an unexpected EOF herein. * Fixes golang#51417 see https://go-review.googlesource.com/c/go/+/14832/
philjb
added a commit
to philjb/go
that referenced
this issue
Mar 1, 2022
For cases where rfc 1952 requires a field, the code returns the error 'unexpected EOF' except in two places: for the FNAME flag or the FCOMMENT flag. These flags expect a null-terminated string and 'readString()' may return an EOF if the Reader is truncated before a null byte is found. For consistency with parsing other parts of the header, this is converted to an unexpected EOF herein. * Fixes golang#51417 see https://go-review.googlesource.com/c/go/+/14832/
philjb
added a commit
to philjb/go
that referenced
this issue
Mar 1, 2022
For cases where rfc 1952 requires a field, the code returns the error 'unexpected EOF' except in two places: for the FNAME flag or the FCOMMENT flag. These flags expect a null-terminated string and 'readString()' may return an EOF if the Reader is truncated before a null byte is found. For consistency with parsing other parts of the header, this is converted to an unexpected EOF herein. * Fixes golang#51417 see https://go-review.googlesource.com/c/go/+/14832/
|
Change https://go.dev/cl/389034 mentions this issue: |
philjb
added a commit
to philjb/go
that referenced
this issue
Mar 2, 2022
For cases where RFC 1952 requires a field, the code returns the error io.ErrUnexpectedEOF except in two places: for the FNAME flag or the FCOMMENT flag. These flags expect a null-terminated string and readString() may return an EOF if the Reader is truncated before a null byte is found. For consistency with parsing other parts of the header, this is converted to an unexpected EOF herein. * Fixes golang#51417 see https://go-review.googlesource.com/c/go/+/14832/
|
Thank you for the bug report and fix! |
dmitshur
added
the
NeedsFix
kortschak
pushed a commit
to biogo/hts
that referenced
this issue
Aug 21, 2022
Due to golang/go#51417 Go1.19 also returns io.ErrUnexpectedEOF for invalid gzip input.
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
When parsing a gzip header with flags set for
FNAMEand/orFCOMMENT, a truncated name or comment returns anEOFinstead ofunexpected EOF.GZIP RFC 1952 https://datatracker.ietf.org/doc/html/rfc1952 specifies that if flags
FNAMEand/orFCOMMENTare set in the header, the corresponding null-terminated strings must also be present.section 2.3.1
The RFC spec just requires an "error indication" (section 2.3.1.2) which
EOFmeets but previous efforts https://go-review.googlesource.com/c/go/+/14832/ (and partly https://go-review.googlesource.com/c/go/+/21466 #15070) returnunexpected EOFwhen the spec requires a field and that field is truncated.I am proposing that two call sites be updated to also return
unexpected EOFfor consistency. See PR #51418What version of Go are you using (
go version)?Does this issue reproduce with the latest release?
yes
What operating system and processor architecture are you using (
go env)?go envOutputWhat did you do?
Attempted to gunzip certain truncated gzip byte streams (see above).
What did you expect to see?
Certain truncated gzip byte streams return an
unexpected EOF.What did you see instead?
Certain truncated gzip byte streams return an
EOF.references
The text was updated successfully, but these errors were encountered: