Control: retitle -1 libmount1 memory corruption affecting libjansson users Hi everyone,
* Michael Biebl <bi...@debian.org> [200627 21:18]: > Control: affects -1 firewalld > > On Sat, 27 Jun 2020 19:46:57 +0200 Guilhem Moulin <guil...@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
