linux-kernel - Re: [PATCH 1/1] lib/zlib: DFLTCC deflate does not write all available bits for Z_NO

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 23 Feb 2023 12:54:02 -0800
From:   Andrew Morton <akpm@...ux-foundation.org>
To:     Mikhail Zaslonko <zaslonko@...ux.ibm.com>
Cc:     Heiko Carstens <hca@...ux.ibm.com>,
        Vasily Gorbik <gor@...ux.ibm.com>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 1/1] lib/zlib: DFLTCC deflate does not write all
 available bits for Z_NO_FLUSH

On Tue, 21 Feb 2023 14:16:17 +0100 Mikhail Zaslonko <zaslonko@...ux.ibm.com> wrote:

> DFLTCC deflate with Z_NO_FLUSH might generate a corrupted stream when
> the output buffer is not large enough to fit all the deflate output at
> once. The problem takes place on closing the deflate block since
> flush_pending() might leave some output bits not written.
> Similar problem for software deflate with Z_BLOCK flush option (not
> supported by kernel zlib deflate) has been fixed a while ago in userspace
> zlib but the fix never got to the kernel.
> Now flush_pending() flushes the bit buffer before copying out the byte buffer,
> in order to really flush as much as possible.
> Currently there are no users of DFLTCC deflate with Z_NO_FLUSH option in the
> kernel so the problem remained hidden for a while.
> 
> This commit is based on the old zlib commit:
> https://github.com/madler/zlib/commit/0b828b4
> 

Thanks.  Does this fix make sense when your series "lib/zlib: Set of
s390 DFLTCC related patches for kernel zlib" is not applied?  If so
then should we backport it in to earlier kernels?

If "no" then are you able to identify a suitable Fixes: tag?  So that
anyone who backports the "lib/zlib: Set of s390 DFLTCC related patches
for kernel zlib" series into an earlier kernel has a better way of
knowing that a fixup is needed.