Backport for CVE-2020-1712 in buster
This series of commits aim to be backports for the upstream fix for CVE-2020-1712.
Peer-review needed in particular for the correct use of sd_bus_message_ref
and other changes which were introduced only after the v241 release upstream.
Merge request reports
Activity
I wonder, do we actually need commit a4a8cf48 , b94e6007 , 0f2b2c13 ie. the bits that make the new API publicly available? To fix the issue at hand, shouldn't it be sufficient to only pull the bits that fix the internal dbus/polkit usage in libshared
Edited by Michael Biebl@biebl yes that's likely possible and indeed sufficient, and not make it as well exposing the new API. I just tried to follow the apporach taken by upstream for their master branch but this might not the best thing to do for backporting.
It looks Ubuntu did take a similar approach, so this might help in verifying the backports. They kept the function public AFAICS, but I guess we can change that and not expose the new API.
For reference: https://usn.ubuntu.com/4269-1/ (with backports to their v229, v237 and v242 based versions).
Edited by Salvatore BonaccorsoHi @carnil, maybe of interest: https://github.com/systemd/systemd-stable/commits/v244-stable Specifically https://github.com/systemd/systemd-stable/commit/83bfc0d8dd026814d23e3fdfa46806394f775526 Upstream also decided to not make this API public in a stable branch. I would follow that. Whether that means dropping that commit completely or simply not exposing it (by not adding it to the .h and .sym file) needs to be evaluated.
This was fixed via ea79ce9e and 65efec96 (cherry-picked from the v241-stable branch) See also https://tracker.debian.org/news/1141026/accepted-systemd-241-7deb10u4-source-into-proposed-updates-stable-new-proposed-updates/
Thanks again, @carnil