[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
kern/44210: gzip support in /usr/src/sys/opencrypto/deflate.c is broken
>Synopsis: gzip support in /usr/src/sys/opencrypto/deflate.c is broken
>Arrival-Date: Thu Dec 09 10:40:00 +0000 2010
>Originator: Dr. W. Stukenbrock
>Release: NetBSD 5.1
Dr. Nagler & Company GmbH
System: NetBSD test-s0 4.0 NetBSD 4.0 (NSW-WS) #0: Tue Aug 17 17:28:09 CEST
2010 wgstuken@test-s0:/usr/src/sys/arch/amd64/compile/NSW-WS amd64
The (initial) gzip support in /usr/src/sys/opencrypto/deflate.c does
not honor the byte-order of
the system it is running on.
When injecting or extracting crc-data or the size information the
byteorder of the host system is assumed.
But this is wrong either on little- or big-endian systems depending on
the correct order for the header.
Next problem may be the alignment of the size and crc fields.
I'm not shure if any compressed data output is always "a multiple of 4
plus 2" long, but I don't think so.
If this is not the case, unaligned data access happend here, that may
be a problem on some architectures.
(remark: 10 bytes header plus compressed data is assumed to be aligned
for u_int32_t ...)
Found by a look into the sources while applying the still open PR's
named below again ....
Correct the problems stated above - sorry I'm not 100% confirm with the
gzip binary format, so
I cannot tell you what macros to use.
In order to avoid alignment problems memcpy() should be used to inject
or extract the u_int32_t values.
Now something different related to the deflate.c file:
I've posted two PR's (for NetBSD 3.1 in 2007) that are still not
integrated into the deflate module.
(kern/36864 and kern/36865)
Perhaps theese can be integrated by time, because I always need to
apply at least 36864 again in order to get deflate working
for our VPN-tunnel setup.
Thanks in advance.
Main Index |
Thread Index |