Bug#963525: Bug#963721: [pkg-cryptsetup-devel] Bug#963721: libcryptsetup12 v2:2.3.3-1 seems to be breaking libssl somehow

[Chris Hofstaedtler]

Control: retitle -1 libmount1 memory corruption affecting libjansson users

Hi everyone,

* Michael Biebl <biebl at debian.org> [200627 21:18]:
> Control: affects -1 firewalld
> 
> On Sat, 27 Jun 2020 19:46:57 +0200 Guilhem Moulin <guilhem at debian.org>
> wrote:
> > On Sat, 27 Jun 2020 at 01:08:49 -0400, Christian Weeks wrote:
> > >> Unless there is a reproducer involving a targeted libcryptsetup12
> > >> upgrade I don't think this belong here :-P  Aside from documentation
> > >> files, the only thing libcryptsetup12 (2:2.1.0-5+deb10u2 and 2:2.3.3-1)
> > >> ships is libcryptsetup.so.12*.  It doesn't touch libssl.
> > > 
> > > It seems that libcryptsetup + the new libmount1 dependency on same are
> > > the root cause somehow. Sorry for the confusion.
> > 
> > To the util-linux maintainers: the following link from #message26 appears
> > relevant: https://github.com/ValveSoftware/steam-for-linux/issues/6861#issuecomment-584379611
> > 
> > Starting with 2.1 cryptsetup upstream started using libssl as
> > cryptographic backend for LUKS header processing; this is already the
> > case in Buster and while other backends are supported I'm very reluctant
> > to diverge from upstream's sane defaults here.
> > 
> > So software dynamically linked against libmount ≥2.35.2-5 will
> > transitively pull in libssl.so.1.1, which due to symbol clashes appears
> > to crash software statically linked against libssl1.0.  Unfortunately
> > I've not been able to find a standalone reproducer using a PoC
> > executable and I didn't look further.
> > 
> > I'm not sure this bug should be RC, or if it's even valid in the first
> > place (it's arguably a steam bug).  Reassigning to libmount1 anyway as
> > the regression follows #951048.

We seem to have multiple problems here:

1) Software that is not shipped by Debian and uses a statically
linked or private copy of libssl crashes, because libmount1 pulls 
in libssl1.1, transitively. This is quite clearly unsupported by
libssl. If anyone ships binaries for Debian, they need to either
link against Debian's libssl, or not use any of the system provided
libs.
This was always a great idea for licensing reasons, and in buster it
was already a great idea for technical reasons, and for bullseye it
will be even more true.
I will not treat this as a release critical bug. Also, there is
probably already more discussion about this in #963525.

> Fwiw, I ran into weird issues with firewalld (a python application)
> which suddenly started to segfault like this:
> 
> [16014.637459] traps: firewalld[35622] general protection fault
> ip:7f981342d7b2 sp:7ffe6abe4ed0 error:0 in
> libjansson.so.4.11.1[7f981342c000+8000]
> 
> Tracing this back (which cost quite a bit of time) showed that the
> libmount1 package upgrade (from -4 to -6) was the culprit. I think this
> bug should very much be RC until this has been figured out.

This appears to be another bug:

2) Some part of libmount1 or libcryptsetup1 introduces a memory
corruption, which is "found" by libjansson users. See also
https://github.com/akheron/jansson/issues/523

Thing is, the verity code that is enabled in util-linux now is very
short; and it does nothing if the mount point has none of the
verity-specific options set.
As such I don't believe this is "my bug". I'll spend some time with
AddressSanitizer enabled builds, but I would urge everyone involved
to take a close look at their packages and maybe also give ASAN and
similar tools a try.

I've retitled this bug (#963721) to investigate the memory
corruption issue. As stated above, I don't intend to spend any time
on code using libssl1.0.

Help is welcome!

Chris