kern/44210: gzip support in /usr/src/sys/opencrypto/deflate.c is broken

[Wolfgang.Stukenbrock%nagler-company.com@localhost]

>Number:         44210
>Category:       kern
>Synopsis:       gzip support in /usr/src/sys/opencrypto/deflate.c is broken
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Thu Dec 09 10:40:00 +0000 2010
>Originator:     Dr. W. Stukenbrock
>Release:        NetBSD 5.1
>Organization:
Dr. Nagler & Company GmbH
>Environment:
        
        
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
Architecture: x86_64
Machine: amd64
>Description:
        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 ...)
>How-To-Repeat:
        Found by a look into the sources while applying the still open PR's 
named below again ....
>Fix:
        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.

>Unformatted: