[UBUNTU 20.04] zlib: inflate() does not update strm.adler if DFLTCC is used

Bug #1990379 reported by bugproxy
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Ubuntu on IBM z Systems
In Progress
Medium
Skipper Bug Screeners
zlib (Ubuntu)
In Progress
High
Unassigned
Focal
Triaged
Undecided
Unassigned
Jammy
Triaged
Undecided
Unassigned
Kinetic
Won't Fix
High
Unassigned

Bug Description

SRU Justification:
------------------

[ Impact ]

 * The zlib function inflate() does not update strm.adler
   in case DFLTCC is used.

 * This issue was exposed by Java Certification Kit (JCK) running on z15
   hardware and newer and impacts all JDK versions (8,11,17, etc.)
   that use the system default settings.

 * The JCK failure impacts the ability to certify Java SDKs on this
   platform/Linux-distribution combination.

 * On top the incorrect alder32 result may cause functional issues with
   Java applications that depend on the result.

[ Test Plan ]

 * An affected Ubuntu release (20.04, 22.04 and 22.10) installed
   on a z15/LinuxONE III or newer system is needed.

 * Then it's possible to test the updated package with the help
   of a small test program (in C) that makes use of the zlib1g library
   or run the Java Certification Kit.

 * Test will be done by IBM.

[ Where problems could occur ]

 * The patch is a one-line change:
   https://launchpadlibrarian.net/626003193/410-lp1990379.patch
   and there are not many issues to expect.

 * There could be a potential problem with the adler field
   in the strm struct.
   For example in case the struct is not as assumed or contains
   and unexpected value, which would then ripple through
   the other fields, too.

 * Structural changes could be identified with a test build that was done
   for all affected Ubuntu releases and for all major architectures:
   https://launchpad.net/~fheimes/+archive/ubuntu/lp1990379

[ Other Info ]

 * The patch itself is the same for all zlib version in
   20.04, 22.04 and 22.10 - no further adjustments were needed.

 * This bug (LP#1990379) is solved in combination with LP#1982583,
   so that only one package update is needed.
   However, this bug affects Kinetic, jammy and Focal,
   but LP#1982583 only Jammy and Kinetic.

 * The debdiffs for Kinetic and Jammy should be taken from LP#1982583,
   and the remaining debdiff for Focal from here.

__________

== Comment: #0 - Ilya Leoshkevich <email address hidden> - 2022-09-21 05:02:24 ==
inflate() does not update strm.adler if DFLTCC is used.

Found with a JDK test.

zlib-ng PR: https://github.com/zlib-ng/zlib-ng/pull/1349

Updated zlib PR: https://github.com/madler/zlib/pull/410

zlib tag: https://github.com/iii-i/zlib/releases/tag/dfltcc-20220920

zlib diff: https://github.com/madler/zlib/compare/e6aed68ff815be74855ec6a19d6ae35065a4adb4..171d0ff3c9ed40da0ac14085ab16b766b1162069#diff-325baa03829572a9f26b4bb8b3cada1ddc637854529d6a6cb111b8c3ca785620

Ubuntu 20.04 and later need to be fixed.

---
External link: https://warthogs.atlassian.net/browse/PEI-28

bugproxy (bugproxy)
tags: added: architecture-s3903164 bugnameltc-200024 severity-medium targetmilestone-inin2004
Changed in ubuntu:
assignee: nobody → Skipper Bug Screeners (skipper-screen-team)
affects: ubuntu → linux (Ubuntu)
Frank Heimes (fheimes)
affects: linux (Ubuntu) → zlib (Ubuntu)
Changed in ubuntu-z-systems:
assignee: nobody → Skipper Bug Screeners (skipper-screen-team)
importance: Undecided → Medium
Revision history for this message
Frank Heimes (fheimes) wrote (last edit ):

Thanks for reporting this, Ilya.
Can you please elaborate about the potential impact of this issue - that 'inflate() does not update strm.adler if DFLTCC is used'?
Especially because this is marked with severity medium, but the Ubuntu stable release update process (SRUs: https://wiki.ubuntu.com/StableReleaseUpdates) is generally in order to fix high-impact bugs.
With updating stable releases (like in this case 20.04 and 22.04) there is huge carefulness needed, and especially with updating key packages and libraries like zlib, since zlib has significant package reverse dependencies and a huge amount of reverse build dependencies (both in the thousands).
Furthermore a potential update will impact multi-millions of installations, cross architecture, and we won't do that for a non-critical bugs, that maybe even only impact a small number of installations.
However, there might be a little chance to piggy-back a fix like this with a more severe zlib update that might come up in future.

Changed in zlib (Ubuntu):
importance: Undecided → Medium
Frank Heimes (fheimes)
Changed in zlib (Ubuntu):
assignee: Skipper Bug Screeners (skipper-screen-team) → nobody
Revision history for this message
bugproxy (bugproxy) wrote : Comment bridged from LTC Bugzilla

However, a chance would be to piggy-back a fix like this with a more severe zlib update that might come up in future.

Revision history for this message
bugproxy (bugproxy) wrote :

------- Comment From <email address hidden> 2022-09-23 13:07 EDT-------
Hi, I am Eclipse OpenJ9 developer. This issue was exposed by Java Certification Kit running on RHEL 9 on z15+ and impacts all JDK versions (8,11,17, etc.) using system default settings. The JCK failure impacts our ability to certify Java SDKs on this platform/distro. Also, the incorrect alder32 result may cause functional issues to Java applications that depend on the result.

Benjamin Drung (bdrung)
tags: added: foundation-triage-discuss
Revision history for this message
Frank Heimes (fheimes) wrote :

So the next step would be to get more clarity on the complexity of the patch that is required.
We have the (initial) PR 410 incl. in the zlib package, plus the patches from LP#1899621 and LP#1961427 on top.
Hence we cannot directly use the new version of PR 410: https://github.com/madler/zlib/pull/410
and also the zlib diff: https://github.com/madler/zlib/compare/e6aed68ff815be74855ec6a19d6ae35065a4adb4..171d0ff3c9ed40da0ac14085ab16b766b1162069#diff-325baa03829572a9f26b4bb8b3cada1ddc637854529d6a6cb111b8c3ca785620
seems to incl. more than just the fix for 'zlib: inflate() does not update strm.adler if DFLTCC is used'.

For example I'm pretty sure that the modifications in contrib/s390/dfltcc.c and infback.c (as listed in the zlib diff) are part of the fix, but since I'm not the author I am unsure if this is everything that's needed.
Are the changes in the crc32 needed on top?
I think the typo fixes can be largely neglected ...

Hence can you please provide us with a patch/backport for the minimal changes that are needed to fix 'zlib: inflate() does not update strm.adler if DFLTCC is used' and that applies on top of what's already in the zlib package (obviously after the quilt patches were applied)?
Ideally based on the kinetic package (but the zlib packages in jammy and focal are pretty close, hence I assume that a backport will apply there too.)

Revision history for this message
bugproxy (bugproxy) wrote : kinetic patch

------- Comment on attachment From <email address hidden> 2022-09-27 20:08 EDT-------

Here is the patch for kinetic. It's just an one liner.

Revision history for this message
Frank Heimes (fheimes) wrote :

Ok, that's a (minimal) patch that can be handled nicely, thanks Ilya!

Test packages are now being build in the following PPA
for focal/20.04, jammy/22.04 and kinetic/22.10:
https://launchpad.net/~fheimes/+archive/ubuntu/lp1990379
https://launchpad.net/~fheimes/+archive/ubuntu/lp1990379/+packages

It would be great if someone (for example 'rahil'?!) could test (probably) at least the focal package upfront, to ensure that the situation is really solved, and with that, give us confidence for the SRU process.
(Please notice that this would be on top of the official verification request that will come up later during the SRU process).

Frank Heimes (fheimes)
description: updated
Changed in zlib (Ubuntu):
status: New → In Progress
Changed in ubuntu-z-systems:
status: New → In Progress
Revision history for this message
Frank Heimes (fheimes) wrote :

debdiffs for F, J and K

Frank Heimes (fheimes)
description: updated
tags: added: pei-28
Revision history for this message
Ubuntu Foundations Team Bug Bot (crichton) wrote :

The attachment "debdiffs.tgz" seems to be a patch. If it isn't, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are a member of the ~ubuntu-reviewers, unsubscribe the team.

[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issues please contact him.]

tags: added: patch
Frank Heimes (fheimes)
Changed in zlib (Ubuntu Focal):
status: New → In Progress
Changed in zlib (Ubuntu Jammy):
status: New → In Progress
Frank Heimes (fheimes)
Changed in zlib (Ubuntu Kinetic):
importance: Medium → High
Revision history for this message
Frank Heimes (fheimes) wrote (last edit ):

I've just noticed another bug that I want to fix with the same package update: LP#1982583
But LP#1982583 affects only jammy and kinetic, not focal.

This means for fixing this bug (LP#1990379) for jammy and kinetic, please use these debdiffs:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/1982583/comments/2
and for fixing this bug (LP#1990379) for focal, please take the focal debdiff from the previous comment:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/1990379/comments/7

Simon Chopin (schopin)
summary: - [UBUNTU 20.04] zlib: inflate() does not update strm.adler if DFLTCC is
- used
+ [FFe][UBUNTU 20.04] zlib: inflate() does not update strm.adler if DFLTCC
+ is used
Frank Heimes (fheimes)
description: updated
Revision history for this message
Julian Andres Klode (juliank) wrote : Re: [FFe][UBUNTU 20.04] zlib: inflate() does not update strm.adler if DFLTCC is used

I looked at the queues for focal and jammy but did not find any zlib uploads as indicated by "in progress" per SRU policy, so reset the status to "triaged".

Changed in zlib (Ubuntu Focal):
status: In Progress → Triaged
Changed in zlib (Ubuntu Jammy):
status: In Progress → Triaged
Frank Heimes (fheimes)
summary: - [FFe][UBUNTU 20.04] zlib: inflate() does not update strm.adler if DFLTCC
- is used
+ [UBUNTU 20.04] zlib: inflate() does not update strm.adler if DFLTCC is
+ used
Revision history for this message
Simon Chopin (schopin) wrote :

Uploaded to Lunar, Kinetic, Jammy and Focal

Revision history for this message
Ilya Leoshkevich (iii-i) wrote :

It has been reported that this change breaks libxml2 (https://bugzilla.redhat.com/show_bug.cgi?id=2155328). The attached patch should fix the issue.

I've also proposed a fix and a new test for zlib-ng (https://github.com/zlib-ng/zlib-ng/pull/1390) in order to detect such breakages in the future.

Revision history for this message
Frank Heimes (fheimes) wrote :

Hi Ilya, yepp, breaking libxml2 is of course an issue.
Regarding the fix/patch, you attached here a patch named 'patch-1.2.11'.

We have currently the following package versions in the archive:
1.2.11.dfsg-2ubuntu1.5 | focal
1.2.11.dfsg-2ubuntu9.2 | jammy
1.2.11.dfsg-4.1ubuntu1 | kinetic
1.2.13.dfsg-1ubuntu3 | lunar-proposed

(After having tweaked the patch a bit regarding white-spaces...)
the patch applies fine on focal, jammy and kinetic.
I wondered if the patch is also for 1.2.13 (I think so, since the RH bug tells that), which is what we currently have in lunar-proposed - and it actually applies there fine too.

I just needed to open a separate LP bug for this, since I need a separate bug number to reference this fix/patch in the changelogs:
https://bugs.launchpad.net/bugs/2002511
So regarding the libxml(2) issue, the further work and communication will be there.

Revision history for this message
Utkarsh Gupta (utkarsh) wrote :

Ubuntu 22.10 (Kinetic Kudu) has reached end of life, so this bug will not be fixed for that specific release.

Changed in zlib (Ubuntu Kinetic):
status: In Progress → Won't Fix
Revision history for this message
bugproxy (bugproxy) wrote : Comment bridged from LTC Bugzilla

------- Comment From <email address hidden> 2023-10-17 10:45 EDT-------
Fix has been released to Focal, Jammy and Kinetic. With 22.10 being out of service, we can close the bug.

==> Changing the status to: "CLOSED"

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.