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] [day] [month] [year] [list]

Message-ID: <95f018c8-aad9-3c5a-7193-7187dd1a85e5@linux.ibm.com>
Date:   Tue, 28 Feb 2023 10:50:28 +0100
From:   Zaslonko Mikhail <zaslonko@...ux.ibm.com>
To:     Andrew Morton <akpm@...ux-foundation.org>
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

Hello Andrew,

On 23.02.2023 21:54, Andrew Morton wrote:
> 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?

This fix is separate and does not require a previous zlib patch series.
Although there are no users of s390 hardware deflate with Z_NO_FLUSH at the moment, 
we might still backport this fix to avoid potential issues in the future.
For all my zlib patches the following tag can be used:
  Fixes: aa5b395b69b6 ("lib/zlib: add s390 hardware support for kernel zlib_deflate")

> 
> 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.
> 

Thanks,
Mikhail