-
Bug
-
Resolution: Unresolved
-
P4
-
8, 11, 17, 22, 23
-
generic
-
generic
ADDITIONAL SYSTEM INFORMATION :
should be independent of OS / used runtime
A DESCRIPTION OF THE PROBLEM :
java.util.zip.DeflaterInputStream violates the block format defined in RFC1951.
STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Use the following code:
var data = "Test".getBytes(StandardCharsets.UTF_8);
var in = new DeflaterInputStream(new ByteArrayInputStream(data));
System.out.printf("0x%x",in.read());
The result is 0x78 (0b01111000). So the first three bits (the block header) are 0b011.
According to RFC1951 section 3.2.3 (https://datatracker.ietf.org/doc/html/rfc1951), a block starting with BTYPE = 0b11 is invalid (reserved).
Let's assume, the bytes have to be interpreted in reverse bit order (which RFC1951 actually allows).
Then we would have 0x1e (0b00011110). So the header is valid (BTYPE = 0b00 = uncompressed).
Section 3.2.3 in the spec states that "skip any remaining bits in current partially processed byte". (I don't understand why there are garbage-bits in here, but that's allowed by the spec.)
The further bytes are then 0x39d0 (LEN) and 0x92b4 (NLEN) (see spec section 3.2.4). But ~0x39d0 != 0x92b4. So also that interpretation is definitely wrong.
FREQUENCY : always
should be independent of OS / used runtime
A DESCRIPTION OF THE PROBLEM :
java.util.zip.DeflaterInputStream violates the block format defined in RFC1951.
STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Use the following code:
var data = "Test".getBytes(StandardCharsets.UTF_8);
var in = new DeflaterInputStream(new ByteArrayInputStream(data));
System.out.printf("0x%x",in.read());
The result is 0x78 (0b01111000). So the first three bits (the block header) are 0b011.
According to RFC1951 section 3.2.3 (https://datatracker.ietf.org/doc/html/rfc1951), a block starting with BTYPE = 0b11 is invalid (reserved).
Let's assume, the bytes have to be interpreted in reverse bit order (which RFC1951 actually allows).
Then we would have 0x1e (0b00011110). So the header is valid (BTYPE = 0b00 = uncompressed).
Section 3.2.3 in the spec states that "skip any remaining bits in current partially processed byte". (I don't understand why there are garbage-bits in here, but that's allowed by the spec.)
The further bytes are then 0x39d0 (LEN) and 0x92b4 (NLEN) (see spec section 3.2.4). But ~0x39d0 != 0x92b4. So also that interpretation is definitely wrong.
FREQUENCY : always