26 May, 2011

1 commit


26 Jan, 2011

1 commit

  • Fix potential use of uninitialised variable caused by recent
    decompressor code optimisations.

    In zlib_uncompress (zlib_wrapper.c) we have

    int zlib_err, zlib_init = 0;
    ...
    do {
    ...
    if (avail == 0) {
    offset = 0;
    put_bh(bh[k++]);
    continue;
    }
    ...
    zlib_err = zlib_inflate(stream, Z_SYNC_FLUSH);
    ...
    } while (zlib_err == Z_OK);

    If continue is executed (avail == 0) then the while condition will be
    evaluated testing zlib_err, which is uninitialised first time around the
    loop.

    Fix this by getting rid of the 'if (avail == 0)' condition test, this
    edge condition should not be being handled in the decompressor code, and
    instead handle it generically in the caller code.

    Similarly for xz_wrapper.c.

    Incidentally, on most architectures (bar Mips and Parisc), no
    uninitialised variable warning is generated by gcc, this is because the
    while condition test on continue is optimised out and not performed
    (when executing continue zlib_err has not been changed since entering
    the loop, and logically if the while condition was true previously, then
    it's still true).

    Signed-off-by: Phillip Lougher
    Reported-by: Jesper Juhl
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Phillip Lougher
     

14 Jan, 2011

1 commit


25 Apr, 2010

1 commit

  • Sizing the buffer based on block size is incorrect, leading
    to a potential buffer over-run on 4K block size file systems
    (because the metadata block size is always 8K). This bug
    doesn't seem have triggered because 4K block size file systems
    are not default, and also because metadata blocks after
    compression tend to be less than 4K.

    Signed-off-by: Phillip Lougher

    Phillip Lougher
     

21 Jan, 2010

3 commits


12 Mar, 2009

1 commit

  • The corrupted filesystem patch added a check against zlib trying to
    output too much data in the presence of data corruption. This check
    triggered if zlib_inflate asked to be called again (Z_OK) with
    avail_out == 0 and no more output buffers available. This check proves
    to be rather dumb, as it incorrectly catches the case where zlib has
    generated all the output, but there are still input bytes to be processed.

    This patch does a number of things. It removes the original check and
    replaces it with code to not move to the next output buffer if there
    are no more output buffers available, relying on zlib to error if it
    wants an extra output buffer in the case of data corruption. It
    also replaces the Z_NO_FLUSH flag with the more correct Z_SYNC_FLUSH
    flag, and makes the error messages more understandable to
    non-technical users.

    Signed-off-by: Phillip Lougher
    Reported-by: Stefan Lippers-Hollmann

    Phillip Lougher
     

05 Mar, 2009

1 commit


05 Jan, 2009

1 commit