Hi, we are running into the bug https://sourceware.org/bugzilla/show_bug.cgi?id=20338 causing systemd-sysusers to segfault. Patch is available in the linked bug report. As it was flagged security in the upstream bugtracker, I'm doing the same here. A fix in buster would be appreciated. Thanks a lot, Bernd
control: forcemerge 967938 969926 Hi, This has already been reported, Florian will work on a backport, as it is not straightforward to backport it to buster due to the usage of private symbols. The bug is actually tagged as security- in the upstream bug tracker, which means it has been reviewed from the security point of view, and hasn't been considered as a security issue. Regards, Aurelien
Hi, Thanks! oh well, I've missed that - in the middle of the night. Sorry for the noise, Bernd
Am Wed, Sep 09, 2020 at 12:30:44PM +0200 schrieb Aurelien Jarno:
Florian, did you manage to backport this to 2.31? It would be nice to get this
fixed for a Buster point release still.
Cheers,
Moritz
Yeah, sorry for the confusion. I meant Buster's 2.28.
Cheers,
Moritz
* Moritz Mühlenhoff: Do you mean 2.28? DJ Delorie did the backport, and Carlos O'Donell implemented the GLIBC_PRIVATE ABI compatibility fix. I'll see if I can get the patches to apply to Debian's 2.28 tree.
Is it possible to commit those patches to the upstream 2.28 branch? If so, I guess we can simply pull the branch in the Debian package, fixing many other security bugs at the same time.
* Aurelien Jarno: I'm concerned about the GLIBC_PRIVATE internal ABI change, it causes issues if the update is applied without a reboot: glibc: After upgrade, before reboot, systemd services using USER= do not start (caused by fix for bug 1871397) <https://bugzilla.redhat.com/show_bug.cgi?id=1927040> I guess we can use Carlos' patch for upstream as well. However, I would also have to backport it to 2.28, 2.29, 2.30, 2.31, so that we have bug fix monotonicity. 2.31 is probably doable, which should help bullseye. It's mostly a psychological thing for me, I'm very busy with getting patches into glibc 2.34 at work, and downstream Debian work would be at least slightly different.
That issue looks problematic for Debian, we usually do not require a (immediate) reboot after applying a security upgrade.
* Aurelien Jarno: I submitted a merge request that should work around it, using the patch from CentOS 8 (and eventually Red Hat Enterprise Linux, of course): <https://salsa.debian.org/glibc-team/glibc/-/merge_requests/2> Please let me know what you think. The new glibc seems to work okay in general.