** Information type changed from Private Security to Public Security -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/2026235
Title: Merge a5e6c8498ca, corrupted resolfconf results in inability to talk to link local DNS servers Status in systemd package in Ubuntu: New Bug description: Package: systemd 249.11-0ubuntu3.9 https://packages.ubuntu.com/jammy/systemd Description: Ubuntu 22.04.2 LTS Release: 22.04 Please merge https://github.com/systemd/systemd/commit/a5e6c8498ca for the Ubuntu LTS release. It's a one-line fix that sets an uninitialized variable to zero. Until this fix is implemented, resolveconf generates incorrect DNS configuration for link-local IPv6 addresses discovered from Router Advertisements (RA). It retrieves the correct address, but then appends a random interface index. So, instead of fe80:xxxx::xxxx, the DNS server reads fe80:xxxx::xxxx%NNN This results in the client no longer being able to reach the locally configured DNS server. This bug can be reproduced by installing a DNS server and radvd (Router Advertisement demon) in an LXC container that shares a network bridge with another container running Ubuntu Jammy. If Jammy is configured to accept RDNSS information from RA, it will set the wrong server address. I believe this only works if radvd advertises a link-local addresses as part of the RDNSS information. If instead, it advertises a globally routable address (e.g. 2001:XXXX::XXXX) there is no issue. While uninitialized memory is always scary, I don't believe this is worse than maybe a denial-of-service attack? So, not quite sure whether this is an exploitable security issue. But that probably depends on exactly how the network topology looks like and whether an attacker can gain (limited) control over manipulating RA packets. It is possible that some clusters and/or containers would suffer security issues because of this problem. Also, this is technically a way to leak memory from within a systemd- related process. But I don't see an obvious way how to exploit this very limited data leak. Out of an abundance of precaution, I am marking this as a security issue. Please feel free to unflag, if you think that assessment isn't warranted. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/2026235/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
