Bug#963721: libcryptsetup12 v2:2.3.3-1 seems to be breaking libssl somehow
* Simon McVittie [200629 17:39]: > On Mon, 29 Jun 2020 at 15:33:48 +0100, Simon McVittie wrote: > > On Sun, 28 Jun 2020 at 15:45:41 +0200, Chris Hofstaedtler wrote: > > > 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. > > ... > > > 2) Some part of libmount1 or libcryptsetup1 introduces a memory > > > corruption, which is "found" by libjansson users. > > > > Also json-glib users, probably (all of json-c, jansson and json-glib > > collide at json_object_iter_next()). > > Given the number of moving parts involved in this, and the fact that the > verity feature is specifically described as experimental in the upstream > release notes, would you be willing to consider reverting the enablement > of the cryptsetup feature until there is at least a concrete plan for > a solution? This is my plan indeed. I'm waiting for bsdmainutils to pass through NEW, as it has a versioned dependency on util-linux 2.35.2-7. > This would reopen #951048, but would at least temporarily > resolve #963721, #963525 and #963933, and would mitigate #963932. Then we > can do a coordinated transition with everything happening in the right > order, when we know what that order is. #951048 is already reopened. > Some possible angles to attack this from: > > - not enabling the feature (Snipped your long list of other options which would need to be done upstream.) > Thanks, > smcv Best, Chris
Bug#963721: libcryptsetup12 v2:2.3.3-1 seems to be breaking libssl somehow
On Mon, 29 Jun 2020 at 15:33:48 +0100, Simon McVittie wrote: > On Sun, 28 Jun 2020 at 15:45:41 +0200, Chris Hofstaedtler wrote: > > 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. > ... > > 2) Some part of libmount1 or libcryptsetup1 introduces a memory > > corruption, which is "found" by libjansson users. > > Also json-glib users, probably (all of json-c, jansson and json-glib > collide at json_object_iter_next()). Given the number of moving parts involved in this, and the fact that the verity feature is specifically described as experimental in the upstream release notes, would you be willing to consider reverting the enablement of the cryptsetup feature until there is at least a concrete plan for a solution? This would reopen #951048, but would at least temporarily resolve #963721, #963525 and #963933, and would mitigate #963932. Then we can do a coordinated transition with everything happening in the right order, when we know what that order is. Some possible angles to attack this from: - not enabling the feature - enabling the feature, but via dlopen rather than linking libcryptsetup normally (the developer who added verity support to util-linux seemed to be in favour of this, although I've lost the relevant tab and can't find a URL right now, sorry) - enabling the feature, but via invoking a helper subprocess - json-c, libjansson and json-glib *all* gaining versioned symbols (but the maintainer of json-glib has previously rejected requests to add versioned symbols, and this doesn't work unless all three libraries do it) - at least two of json-c, libjansson and json-glib renaming their public symbols (the maintainer of json-glib already rejected this, and the maintainers of the others are likely to be equally reluctant to break ABI) - GLib moving from normal linking of libmount to dlopen with RTLD_LOCAL in order to mitigate this by not pulling libmount into everything in the GLib/GNOME/MATE/Cinnamon/XFCE/LXDE ecosystem (but the GLib upstream maintainers don't like this idea and think low-level libraries like libmount should avoid gaining significant dependencies, instead) - changing how Steam links OpenSSL (we cannot do this unilaterally, only its upstream maintainers can; I've raised this upstream with various suggestions, but it would involve significant restructuring, so don't expect immediate results) - changing how other proprietary binary-only software like Minecraft links OpenSSL (we cannot do this unilaterally, only its upstream maintainers can) Thanks, smcv
Bug#963525: Bug#963721: [pkg-cryptsetup-devel] Bug#963721: libcryptsetup12 v2:2.3.3-1 seems to be breaking libssl somehow
On Sun, 28 Jun 2020 at 15:45:41 +0200, Chris Hofstaedtler wrote: > 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. ... > 2) Some part of libmount1 or libcryptsetup1 introduces a memory > corruption, which is "found" by libjansson users. Also json-glib users, probably (all of json-c, jansson and json-glib collide at json_object_iter_next()). See also https://github.com/karelzak/util-linux/issues/1081 and https://gitlab.gnome.org/GNOME/glib/-/issues/2147. smcv
Bug#963721: [pkg-cryptsetup-devel] Bug#963721: libcryptsetup12 v2:2.3.3-1 seems to be breaking libssl somehow
Control: clone -1 -2 Control: retitle -1 libmount1: pulls in libssl, breaking statically-linked-to-libssl software Control: severity -1 wishlist Control: tags -1 wontfix Control: retitle -2 libjson-c and libjansson both export json_object_iter_next Hi Christian, Guilhem, For Steam issues, please see #963525: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=963525 This is a bug in Steam upstream. I imagine the same is true for Minecraft, which I'd expect to ship a statically linked copy of libssl too. This is not something we can fix in Debian. Sorry that there will be no immediate fix; I hope you'll understand. If possible, please tell the people producing Minecraft for Debian that they need to fix their packages. * Michael Biebl [200628 21:27]: > Agreed, this should be tracked separately. > Sorry for hijacking #963721 with that firewalld issue. > To my defence, it appeared to be related due to the libmount1 update > triggering the issue. For this issue, I'll clone this bug and reassign. Best, Chris
Bug#963721: [pkg-cryptsetup-devel] Bug#963721: libcryptsetup12 v2:2.3.3-1 seems to be breaking libssl somehow
Nice work, Chris Am 28.06.20 um 21:16 schrieb Chris Hofstaedtler: > $ ldd /usr/lib/x86_64-linux-gnu/libmount.so.1 > libjson-c.so.4 => /lib/x86_64-linux-gnu/libjson-c.so.4 > (0x7f289aec6000) > ... > > $ ldd /usr/lib/x86_64-linux-gnu/libnftables.so.1 > libjansson.so.4 => /lib/x86_64-linux-gnu/libjansson.so.4 > (0x7f71ffd16000) > ... > > $ nm -Dg /lib/x86_64-linux-gnu/libjson-c.so.4 | grep json_object_iter > 6fe0 T json_object_iter_begin > 7000 T json_object_iter_end > 7040 T json_object_iter_equal > 7050 T json_object_iter_init_default > 7010 T json_object_iter_next > 7020 T json_object_iter_peek_name > 7030 T json_object_iter_peek_value > $ nm -Dg /lib/x86_64-linux-gnu/libjansson.so.4 | grep json_object_iter > 9030 T json_object_iter > 9050 T json_object_iter_at > 90b0 T json_object_iter_key > 9080 T json_object_iter_next > 9b00 T json_object_iter_set_new > 90d0 T json_object_iter_value > > I'm considering cloning and reassinging to json-c and jansson. > Personally I would guess jansson should not export symbols named > json_*, but this is going to be ... interesting. Agreed, this should be tracked separately. Sorry for hijacking #963721 with that firewalld issue. To my defence, it appeared to be related due to the libmount1 update triggering the issue. Regards, Michael signature.asc Description: OpenPGP digital signature
Bug#963721: [pkg-cryptsetup-devel] Bug#963721: libcryptsetup12 v2:2.3.3-1 seems to be breaking libssl somehow
Hi Michael, * Michael Biebl [200628 03:30]: > Am 27.06.20 um 21:14 schrieb Michael Biebl: > > [16014.637459] traps: firewalld[35622] general protection fault > > ip:7f981342d7b2 sp:7ffe6abe4ed0 error:0 in > > libjansson.so.4.11.1[7f981342c000+8000] > > Attached is a back trace. It appears you indeed have found a symbol naming clash! $ ldd /usr/lib/x86_64-linux-gnu/libmount.so.1 libjson-c.so.4 => /lib/x86_64-linux-gnu/libjson-c.so.4 (0x7f289aec6000) ... $ ldd /usr/lib/x86_64-linux-gnu/libnftables.so.1 libjansson.so.4 => /lib/x86_64-linux-gnu/libjansson.so.4 (0x7f71ffd16000) ... $ nm -Dg /lib/x86_64-linux-gnu/libjson-c.so.4 | grep json_object_iter 6fe0 T json_object_iter_begin 7000 T json_object_iter_end 7040 T json_object_iter_equal 7050 T json_object_iter_init_default 7010 T json_object_iter_next 7020 T json_object_iter_peek_name 7030 T json_object_iter_peek_value $ nm -Dg /lib/x86_64-linux-gnu/libjansson.so.4 | grep json_object_iter 9030 T json_object_iter 9050 T json_object_iter_at 90b0 T json_object_iter_key 9080 T json_object_iter_next 9b00 T json_object_iter_set_new 90d0 T json_object_iter_value I'm considering cloning and reassinging to json-c and jansson. Personally I would guess jansson should not export symbols named json_*, but this is going to be ... interesting. Best, Chris
Bug#963525: Bug#963721: [pkg-cryptsetup-devel] Bug#963721: libcryptsetup12 v2:2.3.3-1 seems to be breaking libssl somehow
Control: retitle -1 libmount1 memory corruption affecting libjansson users Hi everyone, * Michael Biebl [200627 21:18]: > Control: affects -1 firewalld > > On Sat, 27 Jun 2020 19:46:57 +0200 Guilhem Moulin > 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
Bug#963721: [pkg-cryptsetup-devel] Bug#963721: libcryptsetup12 v2:2.3.3-1 seems to be breaking libssl somehow
Am 27.06.20 um 21:14 schrieb Michael Biebl:
> [16014.637459] traps: firewalld[35622] general protection fault
> ip:7f981342d7b2 sp:7ffe6abe4ed0 error:0 in
> libjansson.so.4.11.1[7f981342c000+8000]
Attached is a back trace.
Starting program: /usr/bin/python3 /usr/sbin/firewalld --nofork
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[Detaching after fork from child process 20346]
[Detaching after fork from child process 20347]
[Detaching after fork from child process 20348]
[Detaching after fork from child process 20349]
[Detaching after fork from child process 20350]
[Detaching after fork from child process 20351]
[Detaching after fork from child process 20352]
[Detaching after fork from child process 20353]
[Detaching after fork from child process 20354]
[Detaching after fork from child process 20355]
[Detaching after fork from child process 20356]
[Detaching after fork from child process 20357]
[Detaching after fork from child process 20358]
[Detaching after fork from child process 20359]
[Detaching after fork from child process 20360]
[Detaching after fork from child process 20361]
[Detaching after fork from child process 20362]
[Detaching after fork from child process 20363]
[Detaching after fork from child process 20364]
[Detaching after fork from child process 20365]
[Detaching after fork from child process 20366]
[Detaching after fork from child process 20367]
[Detaching after fork from child process 20368]
[Detaching after fork from child process 20369]
[Detaching after fork from child process 20370]
[Detaching after fork from child process 20371]
[Detaching after fork from child process 20372]
[Detaching after fork from child process 20373]
[Detaching after fork from child process 20375]
[Detaching after fork from child process 20376]
Program received signal SIGSEGV, Segmentation fault.
hashtable_find_pair (hashtable=hashtable@entry=0xc00910, bucket=0xb85611,
key=key@entry=0x74fae498 "json_schema_version", hash=2919860699) at
hashtable.c:93
93 hashtable.c: Datei oder Verzeichnis nicht gefunden.
#0 hashtable_find_pair (hashtable=hashtable@entry=0xc00910, bucket=0xb85611,
key=key@entry=0x74fae498 "json_schema_version", hash=2919860699)
at hashtable.c:93
list = 0x2800c009
pair = 0x2800c009
#1 0x74eefc24 in hashtable_get (hashtable=0xc00910, key=0x74fae498
"json_schema_version") at hashtable.c:279
pair =
hash =
bucket =
#2 0x74ef22e8 in unpack_object (ap=0x7fffb7a0, root=0xc00900,
s=0x7fffb720) at pack_unpack.c:551
key = 0x74fae498 "json_schema_version"
value =
opt = 0
ret = -1
strict = 0
gotopt =
key_set =
{size = 0, buckets = 0xb49560, order = 3, list = {prev =
0x7fffb6b8, next = 0x7fffb6b8}, ordered_list = {prev = 0x7fffb6c8,
next = 0x7fffb6c8}}
#3 unpack (s=0x7fffb720, root=root@entry=0xc00900,
ap=ap@entry=0x7fffb7a0) at pack_unpack.c:686
#4 0x74ef3a2a in json_vunpack_ex
(root=0xc00900, error=error@entry=0x0, flags=flags@entry=0,
fmt=fmt@entry=0x74fae3a5 "{s:i}", ap=ap@entry=0x7fffb800) at
pack_unpack.c:915
s =
{start = 0x74fae3a5 "{s:i}", fmt = 0x74fae3a9 "}", prev_token
= {line = 1, column = 2, pos = 2, token = 115 's'}, token = {line = 1, column =
4, pos = 4, token = 105 'i'}, next_token = {line = 0, column = 0, pos = 0,
token = 0 '\000'}, error = 0x0, flags = 0, line = 1, column = 4, pos = 4,
has_error = 0}
ap_copy = {{gp_offset = 24, fp_offset = 48, overflow_arg_area =
0x7fffb8e0, reg_save_area = 0x7fffb820}}
#5 0x74ef3c4b in json_unpack (root=,
fmt=fmt@entry=0x74fae3a5 "{s:i}") at pack_unpack.c:948
ret =
ap = {{gp_offset = 16, fp_offset = 48, overflow_arg_area =
0x7fffb8e0, reg_save_area = 0x7fffb820}}
#6 0x74f8dc0a in json_verify_metainfo (root=,
ctx=0x7fffba40) at parser_json.c:3713
schema_version = 0
list = {next = 0x7fffb900, prev = 0x7fffb900}
cmd =
tmp2 =
tmp = 0xcdba00
value = 0xc00900
index = 0
#7 __json_parse (ctx=ctx@entry=0x7fffba40) at parser_json.c:3713
list = {next = 0x7fffb900, prev = 0x7fffb900}
cmd =
tmp2 =
tmp = 0xcdba00
value = 0xc00900
index = 0
#8 0x74f93dba in nft_parse_json_buffer
(nft=nft@entry=0xc4c800, buf=buf@entry=0xb37c00 "{\"nftables\":
[{\"metainfo\": {\"json_schema_version\": 1}}, {\"add\": {\"table\":
{\"family\": \"inet\", \"name\": \"firewalld\"}}}, {\"add\": {\"table\":
{\"family\": \"ip\", \"name\": \"firewalld\"}}}, {\"add\": {\"table\":
{\"fami"..., msgs=msgs@entry=0x7fffbb00, cmds=cmds@entry=0x7fffbb10) at
parser_json.c:3756
ctx =
{indesc = {list = {next = 0x0, prev =
Bug#963721: [pkg-cryptsetup-devel] Bug#963721: libcryptsetup12 v2:2.3.3-1 seems to be breaking libssl somehow
Control: affects -1 firewalld On Sat, 27 Jun 2020 19:46:57 +0200 Guilhem Moulin wrote: > Control: reassign -1 libmount1 > Control: found -1 2.35.2-6 > Control: retitle -1 libmount1 pulls in libssl 1.1 and breaks software > statically linked against libcrypto 1.0 > > 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. 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. Regards, Michael signature.asc Description: OpenPGP digital signature
Bug#963721: [pkg-cryptsetup-devel] Bug#963721: libcryptsetup12 v2:2.3.3-1 seems to be breaking libssl somehow
Control: reassign -1 libmount1 Control: found -1 2.35.2-6 Control: retitle -1 libmount1 pulls in libssl 1.1 and breaks software statically linked against libcrypto 1.0 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. Cheers, -- Guilhem. signature.asc Description: PGP signature
Bug#963721: [pkg-cryptsetup-devel] Bug#963721: libcryptsetup12 v2:2.3.3-1 seems to be breaking libssl somehow
On Sat, 2020-06-27 at 04:35 +0200, Guilhem Moulin wrote: > On Fri, 26 Jun 2020 at 20:39:32 -0400, Christian Weeks wrote: > > After some more googling, it seems that the REAL culprit might be > > libmount1. > > Should this be reassigned to util-linux/2.35.2-5 then? I guess so? I don't know how to do that. > > > This seems like a really messy tangled web of nastiness. Good luck > > figuring it out. > > 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.
Bug#963721: [pkg-cryptsetup-devel] Bug#963721: libcryptsetup12 v2:2.3.3-1 seems to be breaking libssl somehow
On Fri, 26 Jun 2020 at 20:39:32 -0400, Christian Weeks wrote: > After some more googling, it seems that the REAL culprit might be > libmount1. Should this be reassigned to util-linux/2.35.2-5 then? > This seems like a really messy tangled web of nastiness. Good luck > figuring it out. 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. -- Guilhem. signature.asc Description: PGP signature
Bug#963721: [pkg-cryptsetup-devel] Bug#963721: libcryptsetup12 v2:2.3.3-1 seems to be breaking libssl somehow
On Fri, 26 Jun 2020 at 11:40:31 -0400, Christian Weeks wrote: > Attached is the output of the various console commands, as well > as the backtrace from the broken launcher with the new lib. Thanks, however I fail to see how libcryptsetup12 is involved. (Also I think we can rule out i386 since the crash happens with x86_64.) Is that the entire reproducer? - launcher works with libcryptsetup12:amd64 2:2.1.0-5+deb10u2 - `apt upgrade libcryptsetup12:amd64` (from 2:2.1.0-5+deb10u2 to 2:2.3.3-1, and *only* this package) - launcher no longer works Do you confirm that the backtrace you shared previously was part of this reproducer, and not something saved from a previous environment? I see no mention of libcryptsetup there, so I don't see how it comes to the picture. -- Guilhem. signature.asc Description: PGP signature
Bug#963721: [pkg-cryptsetup-devel] Bug#963721: libcryptsetup12 v2:2.3.3-1 seems to be breaking libssl somehow
Update. I just discovered steam is still broken. After some more googling, it seems that the REAL culprit might be libmount1. Specifically, it seems that libmount1 v2.35.2-5 (bug #951048) has started building with libcryptsetup-dev, but that is causing weird SSL leakages everywhere, crashing unrelated software (minecraft launcher, steam, other stuff using SSL). I have upgraded libcryptsetup12 and downgraded libmount1 to 2.35.2-4 and it has resolved the problem as well. This seems like a really messy tangled web of nastiness. Good luck figuring it out. I'm going to speculate that the guys at Mandriva found a similar problem: https://github.com/ValveSoftware/steam-for-linux/issues/6861 Perhaps they might have a solution too? Thanks On Fri, 2020-06-26 at 11:40 -0400, Christian Weeks wrote: > Attached is the output of the various console commands, as well > as the backtrace from the broken launcher with the new lib. > > Note that I am installing both amd64 and i386 versions. I do not > have cryptsetup even installed on this machine, I think this lib > is coming in from a dependency in gnome disks. > > There is one key difference: in the older version, there is an > explicit libssl in the linker, but in the new version, there > is not, even though it is somehow still being loaded. > > Perhaps another lib is pulling a differing version somehow, and > this lib is stamping on it? > > Thanks! > > On Fri, 2020-06-26 at 17:23 +0200, Guilhem Moulin wrote: > > Control: tag -1 moreinfo > > > > Hi Christian, > > > > On Thu, 25 Jun 2020 at 21:58:43 -0400, Christian Weeks wrote: > > > I installed the newest version of libcryptsetup12. > > > > Unfortunately you appeared to file this bug using Buster's > > libcryptsetup12 so the metada doesn't describe the buggy environment > > (Version: 2:2.1.0-5+deb10u2). Please show the output of `apt upgrade > > libcryptsetup12` that yields the buggy environment. (I.e., you don't > > encounter the bug before the command but do after the upgrade.) The > > output of > > > > ldd /lib/*-linux-gnu/libcryptsetup.so.12.6.0 /sbin/cryptsetup > > > > and > > > > dpkg-query -l "*cryptsetup*" > > > > before *and* after the upgrade might be helpful too. > > > > > Suddenly, minecraft would not run! > > > Backtraces in gdb indicate that something is broken in SSL. > > > > Care to share said backtrace also? > > > > cheers
Bug#963721: [pkg-cryptsetup-devel] Bug#963721: libcryptsetup12 v2:2.3.3-1 seems to be breaking libssl somehow
Attached is the output of the various console commands, as well as the backtrace from the broken launcher with the new lib. Note that I am installing both amd64 and i386 versions. I do not have cryptsetup even installed on this machine, I think this lib is coming in from a dependency in gnome disks. There is one key difference: in the older version, there is an explicit libssl in the linker, but in the new version, there is not, even though it is somehow still being loaded. Perhaps another lib is pulling a differing version somehow, and this lib is stamping on it? Thanks! On Fri, 2020-06-26 at 17:23 +0200, Guilhem Moulin wrote: > Control: tag -1 moreinfo > > Hi Christian, > > On Thu, 25 Jun 2020 at 21:58:43 -0400, Christian Weeks wrote: > > I installed the newest version of libcryptsetup12. > > Unfortunately you appeared to file this bug using Buster's > libcryptsetup12 so the metada doesn't describe the buggy environment > (Version: 2:2.1.0-5+deb10u2). Please show the output of `apt upgrade > libcryptsetup12` that yields the buggy environment. (I.e., you don't > encounter the bug before the command but do after the upgrade.) The > output of > > ldd /lib/*-linux-gnu/libcryptsetup.so.12.6.0 /sbin/cryptsetup > > and > > dpkg-query -l "*cryptsetup*" > > before *and* after the upgrade might be helpful too. > > > Suddenly, minecraft would not run! > > Backtraces in gdb indicate that something is broken in SSL. > > Care to share said backtrace also? > > cheers /lib/i386-linux-gnu/libcryptsetup.so.12.4.0: linux-gate.so.1 (0xf7f31000) libuuid.so.1 => /lib/i386-linux-gnu/libuuid.so.1 (0xf7e83000) libdevmapper.so.1.02.1 => /lib/i386-linux-gnu/libdevmapper.so.1.02.1 (0xf7e1e000) libssl.so.1.1 => /lib/i386-linux-gnu/libssl.so.1.1 (0xf7d87000) libcrypto.so.1.1 => /lib/i386-linux-gnu/libcrypto.so.1.1 (0xf7ac4000) libargon2.so.1 => /lib/i386-linux-gnu/libargon2.so.1 (0xf7ab6000) librt.so.1 => /lib/i386-linux-gnu/librt.so.1 (0xf7aac000) libdl.so.2 => /lib/i386-linux-gnu/libdl.so.2 (0xf7aa6000) libjson-c.so.3 => /lib/i386-linux-gnu/libjson-c.so.3 (0xf7a99000) libblkid.so.1 => /lib/i386-linux-gnu/libblkid.so.1 (0xf7a3e000) libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xf785a000) /lib/ld-linux.so.2 (0xf7f33000) libselinux.so.1 => /lib/i386-linux-gnu/libselinux.so.1 (0xf782b000) libudev.so.1 => /lib/i386-linux-gnu/libudev.so.1 (0xf77ff000) libm.so.6 => /lib/i386-linux-gnu/libm.so.6 (0xf76fb000) libpthread.so.0 => /lib/i386-linux-gnu/libpthread.so.0 (0xf76d9000) libpcre2-8.so.0 => /lib/i386-linux-gnu/libpcre2-8.so.0 (0xf7642000) /lib/x86_64-linux-gnu/libcryptsetup.so.12.4.0: linux-vdso.so.1 (0x7ffefefa) libuuid.so.1 => /lib/x86_64-linux-gnu/libuuid.so.1 (0x7f8855e44000) libdevmapper.so.1.02.1 => /lib/x86_64-linux-gnu/libdevmapper.so.1.02.1 (0x7f8855dd8000) libssl.so.1.1 => /lib/x86_64-linux-gnu/libssl.so.1.1 (0x7f8855d46000) libcrypto.so.1.1 => /lib/x86_64-linux-gnu/libcrypto.so.1.1 (0x7f8855a5a000) libargon2.so.1 => /lib/x86_64-linux-gnu/libargon2.so.1 (0x7f8855a5) librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x7f8855a45000) libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7f8855a3e000) libjson-c.so.3 => /lib/x86_64-linux-gnu/libjson-c.so.3 (0x7f8855a31000) libblkid.so.1 => /lib/x86_64-linux-gnu/libblkid.so.1 (0x7f88559e) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f885581d000) /lib64/ld-linux-x86-64.so.2 (0x7f8855eda000) libselinux.so.1 => /lib/x86_64-linux-gnu/libselinux.so.1 (0x7f88557f2000) libudev.so.1 => /lib/x86_64-linux-gnu/libudev.so.1 (0x7f88557c6000) libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7f885567f000) libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x7f885565e000) libpcre2-8.so.0 => /lib/x86_64-linux-gnu/libpcre2-8.so.0 (0x7f88555ce000) /sbin/cryptsetup: ldd: /sbin/cryptsetup: No such file or directory dpkg-query -l "*cryptsetup*" Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ Name Version Architecture Description +++-=-=-- un cryptsetup-initramfs (no description available) ii libcryptsetup12:amd64 2:2.1.0-5+deb10u2 amd64disk encryption support - shared library ii libcryptsetup12:i386 2:2.1.0-5+deb10u2 i386 disk encryption support - shared library sudo apt install libcryptsetup12 libcryptsetup12:i386 Reading package lists... Done Building dependency tree Reading state information... Done The following
Bug#963721: [pkg-cryptsetup-devel] Bug#963721: libcryptsetup12 v2:2.3.3-1 seems to be breaking libssl somehow
Control: tag -1 moreinfo Hi Christian, On Thu, 25 Jun 2020 at 21:58:43 -0400, Christian Weeks wrote: > I installed the newest version of libcryptsetup12. Unfortunately you appeared to file this bug using Buster's libcryptsetup12 so the metada doesn't describe the buggy environment (Version: 2:2.1.0-5+deb10u2). Please show the output of `apt upgrade libcryptsetup12` that yields the buggy environment. (I.e., you don't encounter the bug before the command but do after the upgrade.) The output of ldd /lib/*-linux-gnu/libcryptsetup.so.12.6.0 /sbin/cryptsetup and dpkg-query -l "*cryptsetup*" before *and* after the upgrade might be helpful too. > Suddenly, minecraft would not run! > Backtraces in gdb indicate that something is broken in SSL. Care to share said backtrace also? cheers -- Guilhem. signature.asc Description: PGP signature
Bug#963721: libcryptsetup12 v2:2.3.3-1 seems to be breaking libssl somehow
Package: libcryptsetup12 Version: 2:2.1.0-5+deb10u2 Severity: critical Justification: breaks unrelated software Dear Maintainer, * What led up to the situation? I installed the newest version of libcryptsetup12. Suddenly, minecraft would not run! Backtraces in gdb indicate that something is broken in SSL. Reverting libcryptsetup12 to the buster version fixed the issue immediately. * What exactly did you do (or not do) that was effective (or ineffective)? Reverting to the buster version of libcryptsetup12. I would have picked the previous version 2.3.2 but I don't have the deb handy. * What was the outcome of this action? The spurious SSL issues were resolved and I can play again. * What outcome did you expect instead? -- Package-specific info: -- System Information: Debian Release: bullseye/sid APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.6.0-2-amd64 (SMP w/24 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), LANGUAGE=en_CA:en (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libcryptsetup12 depends on: ii libargon2-1 0~20171227-0.2 ii libblkid1 2.35.2-5 ii libc6 2.30-8 ii libdevmapper1.02.1 2:1.02.167-1+b1 ii libjson-c3 0.12.1+ds-2 ii libssl1.1 1.1.1g-1 ii libuuid12.35.2-5 libcryptsetup12 recommends no packages. libcryptsetup12 suggests no packages. -- no debconf information
