** Description changed: [ Impact ] dnsmasq "keeps an eye" on /etc/resolv.conf, and reloads it whenever the file is updated. When that happens and for some reason there were no "nameserver" declarations in the updated file, dnsmasq can crash. Here is a log of a reproducer: $ dig +short @127.0.0.1 ubuntu.com ;; communications error to 127.0.0.1#53: timed out ;; communications error to 127.0.0.1#53: connection refused ;; communications error to 127.0.0.1#53: connection refused ;; no servers could be reached We can see the startup, then when resolv.conf is read again and no nameservers were found, and the crash: Jan 03 13:57:13 j-dnsmasq-2045570 dnsmasq[1507]: started, version 2.86 cachesize 150 Jan 03 13:57:13 j-dnsmasq-2045570 dnsmasq[1507]: DNS service limited to local subnets Jan 03 13:57:13 j-dnsmasq-2045570 dnsmasq[1507]: compile time options: IPv6 GNU-getopt DBus no-UBus i18n IDN2 DHCP DHCPv6 no-Lua TFTP conntrack ipset auth cryptohash DNSSEC loop-detect inotify dumpfile Jan 03 13:57:13 j-dnsmasq-2045570 dnsmasq[1507]: reading /etc/resolv.conf Jan 03 13:57:13 j-dnsmasq-2045570 dnsmasq[1507]: using nameserver 10.0.100.1#53 Jan 03 13:57:13 j-dnsmasq-2045570 dnsmasq[1507]: read /etc/hosts - 7 addresses Jan 03 13:57:13 j-dnsmasq-2045570 systemd[1]: Started dnsmasq - A lightweight DHCP and caching DNS server. Jan 03 13:58:01 j-dnsmasq-2045570 dnsmasq[1507]: no servers found in /etc/resolv.conf, will retry Jan 03 13:58:22 j-dnsmasq-2045570 systemd[1]: dnsmasq.service: Main process exited, code=dumped, status=11/SEGV Jan 03 13:58:22 j-dnsmasq-2045570 systemd[1]: dnsmasq.service: Failed with result 'core-dump'. dnsmasq has provisions for this situation, we can see that in the 13:58:01 message where it says it will retry, but due to this bug, it crashes instead. + [ Test Plan ] + It might take a few tries to reproduce the bug, but here is the general outline. Also keep in mind that it's important to use a DNS name that isn't cached already by a previous query. - [ Test Plan ] + # Create a jammy lxd container - * detailed instructions how to reproduce the bug + lxc launch ubuntu-daily:jammy j-dnsmasq-2045570 - * these should allow someone who is not familiar with the affected - package to reproduce the bug and verify that the updated package fixes - the problem. + # Enter the container - * if other testing is appropriate to perform before landing this update, - this should also be described here. + lxc shell j-dnsmasq-2045570 + + # From now on, all commands should be executed in the container. + # Install dnsmasq, and disable systemd-resolved + + apt update && apt install -y dnsmasq + + # Disable systemd-resolved, and start dnsmasq + + systemctl disable --now systemd-resolved + systemctl enable --now dnsmasq + + # In one terminal inside the container, watch the dnsmasq logs: + + journalctl -u dnsmasq.service -f + + # In another terminal, remove /etc/resolv.conf and create a new one, empty + rm /etc/resolv.conf + touch /etc/resolv.conf + + # Note in the dnsmasq logs that it should notice the resolv.conf changes, with something like: + Jan 03 13:58:01 j-dnsmasq-2045570 dnsmasq[1507]: no servers found in /etc/resolv.conf, will retry + + # Perform a dns query + + dig @127.0.0.1 +short ubuntu.com + + # Observe in the dnsmasq logs that it crashes. + Jan 03 13:58:22 j-dnsmasq-2045570 systemd[1]: dnsmasq.service: Main process exited, code=dumped, status=11/SEGV + Jan 03 13:58:22 j-dnsmasq-2045570 systemd[1]: dnsmasq.service: Failed with result 'core-dump'. + + If it doesn't crash right away, repeat these steps a few times, but using a different domain name each time: + - add "nameserver 127.0.0.1" to /etc/resolv.conf + - observe that dnsmasq notices the change to the file + - perform a query for some random domain using "dig @127.0.0.1 +short <domain-of-your-choosing>" + - remove "nameserver" from /etc/resolv.conf, observe that dnsmasq noticed the change + - perform a query for another random domain + + The fixed version from proposed will not crash. + [ Where problems could occur ] * Think about what the upload changes in the software. Imagine the change is wrong or breaks something else: how would this show up? * It is assumed that any SRU candidate patch is well-tested before upload and has a low overall risk of regression, but it's important to make the effort to think about what ''could'' happen in the event of a regression. * This must '''never''' be "None" or "Low", or entirely an argument as to why your upload is low risk. * This both shows the SRU team that the risks have been considered, and provides guidance to testers in regression-testing the SRU. [ Other Info ] * Anything else you think is useful to include * Anticipate questions from users, SRU, +1 maintenance, security teams and the Technical Board * and address these questions in advance [ Original description ] upstream discussion: https://lists.thekelleys.org.uk/pipermail/dnsmasq- discuss/2022q3/016563.html in my journal, my dns service crash and restart just after: Dec 04 17:18:38 dnsmasq[199333]: no servers found in /run/NetworkManager/no-stub-resolv.conf, will retry oops report: https://errors.ubuntu.com/oops/29cf5e2e-92b1-11ee-9bdf- fa163ec44ecd ubuntu jammy, dnsmasq-base 2.86-1.1ubuntu0.3
** Description changed: [ Impact ] dnsmasq "keeps an eye" on /etc/resolv.conf, and reloads it whenever the file is updated. When that happens and for some reason there were no "nameserver" declarations in the updated file, dnsmasq can crash. Here is a log of a reproducer: $ dig +short @127.0.0.1 ubuntu.com ;; communications error to 127.0.0.1#53: timed out ;; communications error to 127.0.0.1#53: connection refused ;; communications error to 127.0.0.1#53: connection refused ;; no servers could be reached We can see the startup, then when resolv.conf is read again and no nameservers were found, and the crash: Jan 03 13:57:13 j-dnsmasq-2045570 dnsmasq[1507]: started, version 2.86 cachesize 150 Jan 03 13:57:13 j-dnsmasq-2045570 dnsmasq[1507]: DNS service limited to local subnets Jan 03 13:57:13 j-dnsmasq-2045570 dnsmasq[1507]: compile time options: IPv6 GNU-getopt DBus no-UBus i18n IDN2 DHCP DHCPv6 no-Lua TFTP conntrack ipset auth cryptohash DNSSEC loop-detect inotify dumpfile Jan 03 13:57:13 j-dnsmasq-2045570 dnsmasq[1507]: reading /etc/resolv.conf Jan 03 13:57:13 j-dnsmasq-2045570 dnsmasq[1507]: using nameserver 10.0.100.1#53 Jan 03 13:57:13 j-dnsmasq-2045570 dnsmasq[1507]: read /etc/hosts - 7 addresses Jan 03 13:57:13 j-dnsmasq-2045570 systemd[1]: Started dnsmasq - A lightweight DHCP and caching DNS server. Jan 03 13:58:01 j-dnsmasq-2045570 dnsmasq[1507]: no servers found in /etc/resolv.conf, will retry Jan 03 13:58:22 j-dnsmasq-2045570 systemd[1]: dnsmasq.service: Main process exited, code=dumped, status=11/SEGV Jan 03 13:58:22 j-dnsmasq-2045570 systemd[1]: dnsmasq.service: Failed with result 'core-dump'. dnsmasq has provisions for this situation, we can see that in the 13:58:01 message where it says it will retry, but due to this bug, it crashes instead. [ Test Plan ] It might take a few tries to reproduce the bug, but here is the general outline. Also keep in mind that it's important to use a DNS name that isn't cached already by a previous query. # Create a jammy lxd container lxc launch ubuntu-daily:jammy j-dnsmasq-2045570 # Enter the container lxc shell j-dnsmasq-2045570 # From now on, all commands should be executed in the container. # Install dnsmasq, and disable systemd-resolved apt update && apt install -y dnsmasq # Disable systemd-resolved, and start dnsmasq systemctl disable --now systemd-resolved systemctl enable --now dnsmasq # In one terminal inside the container, watch the dnsmasq logs: journalctl -u dnsmasq.service -f # In another terminal, remove /etc/resolv.conf and create a new one, empty rm /etc/resolv.conf - touch /etc/resolv.conf + echo "nameserver 1.1.1.1" > /etc/resolv.conf # Note in the dnsmasq logs that it should notice the resolv.conf changes, with something like: Jan 03 13:58:01 j-dnsmasq-2045570 dnsmasq[1507]: no servers found in /etc/resolv.conf, will retry # Perform a dns query dig @127.0.0.1 +short ubuntu.com # Observe in the dnsmasq logs that it crashes. Jan 03 13:58:22 j-dnsmasq-2045570 systemd[1]: dnsmasq.service: Main process exited, code=dumped, status=11/SEGV Jan 03 13:58:22 j-dnsmasq-2045570 systemd[1]: dnsmasq.service: Failed with result 'core-dump'. If it doesn't crash right away, repeat these steps a few times, but using a different domain name each time: - add "nameserver 127.0.0.1" to /etc/resolv.conf - observe that dnsmasq notices the change to the file - perform a query for some random domain using "dig @127.0.0.1 +short <domain-of-your-choosing>" - remove "nameserver" from /etc/resolv.conf, observe that dnsmasq noticed the change - perform a query for another random domain The fixed version from proposed will not crash. - [ Where problems could occur ] * Think about what the upload changes in the software. Imagine the change is wrong or breaks something else: how would this show up? * It is assumed that any SRU candidate patch is well-tested before upload and has a low overall risk of regression, but it's important to make the effort to think about what ''could'' happen in the event of a regression. * This must '''never''' be "None" or "Low", or entirely an argument as to why your upload is low risk. * This both shows the SRU team that the risks have been considered, and provides guidance to testers in regression-testing the SRU. [ Other Info ] * Anything else you think is useful to include * Anticipate questions from users, SRU, +1 maintenance, security teams and the Technical Board * and address these questions in advance [ Original description ] upstream discussion: https://lists.thekelleys.org.uk/pipermail/dnsmasq- discuss/2022q3/016563.html in my journal, my dns service crash and restart just after: Dec 04 17:18:38 dnsmasq[199333]: no servers found in /run/NetworkManager/no-stub-resolv.conf, will retry oops report: https://errors.ubuntu.com/oops/29cf5e2e-92b1-11ee-9bdf- fa163ec44ecd ubuntu jammy, dnsmasq-base 2.86-1.1ubuntu0.3 ** Description changed: [ Impact ] dnsmasq "keeps an eye" on /etc/resolv.conf, and reloads it whenever the file is updated. When that happens and for some reason there were no "nameserver" declarations in the updated file, dnsmasq can crash. Here is a log of a reproducer: $ dig +short @127.0.0.1 ubuntu.com ;; communications error to 127.0.0.1#53: timed out ;; communications error to 127.0.0.1#53: connection refused ;; communications error to 127.0.0.1#53: connection refused ;; no servers could be reached We can see the startup, then when resolv.conf is read again and no nameservers were found, and the crash: Jan 03 13:57:13 j-dnsmasq-2045570 dnsmasq[1507]: started, version 2.86 cachesize 150 Jan 03 13:57:13 j-dnsmasq-2045570 dnsmasq[1507]: DNS service limited to local subnets Jan 03 13:57:13 j-dnsmasq-2045570 dnsmasq[1507]: compile time options: IPv6 GNU-getopt DBus no-UBus i18n IDN2 DHCP DHCPv6 no-Lua TFTP conntrack ipset auth cryptohash DNSSEC loop-detect inotify dumpfile Jan 03 13:57:13 j-dnsmasq-2045570 dnsmasq[1507]: reading /etc/resolv.conf Jan 03 13:57:13 j-dnsmasq-2045570 dnsmasq[1507]: using nameserver 10.0.100.1#53 Jan 03 13:57:13 j-dnsmasq-2045570 dnsmasq[1507]: read /etc/hosts - 7 addresses Jan 03 13:57:13 j-dnsmasq-2045570 systemd[1]: Started dnsmasq - A lightweight DHCP and caching DNS server. Jan 03 13:58:01 j-dnsmasq-2045570 dnsmasq[1507]: no servers found in /etc/resolv.conf, will retry Jan 03 13:58:22 j-dnsmasq-2045570 systemd[1]: dnsmasq.service: Main process exited, code=dumped, status=11/SEGV Jan 03 13:58:22 j-dnsmasq-2045570 systemd[1]: dnsmasq.service: Failed with result 'core-dump'. dnsmasq has provisions for this situation, we can see that in the 13:58:01 message where it says it will retry, but due to this bug, it crashes instead. [ Test Plan ] It might take a few tries to reproduce the bug, but here is the general outline. Also keep in mind that it's important to use a DNS name that isn't cached already by a previous query. # Create a jammy lxd container lxc launch ubuntu-daily:jammy j-dnsmasq-2045570 # Enter the container lxc shell j-dnsmasq-2045570 # From now on, all commands should be executed in the container. # Install dnsmasq, and disable systemd-resolved apt update && apt install -y dnsmasq # Disable systemd-resolved, and start dnsmasq systemctl disable --now systemd-resolved systemctl enable --now dnsmasq # In one terminal inside the container, watch the dnsmasq logs: journalctl -u dnsmasq.service -f # In another terminal, remove /etc/resolv.conf and create a new one, empty rm /etc/resolv.conf echo "nameserver 1.1.1.1" > /etc/resolv.conf - # Note in the dnsmasq logs that it should notice the resolv.conf changes, with something like: - Jan 03 13:58:01 j-dnsmasq-2045570 dnsmasq[1507]: no servers found in /etc/resolv.conf, will retry + # restart dnsmasq + systemctl restart dnsmasq.service # Perform a dns query + + dig @127.0.0.1 +short linux.com + + # Comment the namserver directive in resolv.conf + echo "#nameserver 1.1.1.1" > /etc/resolv.conf + + # Observe in the dnsmasq logs that it notices the change with a message + like: + + Jan 03 14:14:51 j-dnsmasq-2045570 dnsmasq[2274]: no servers found in + /etc/resolv.conf, will retry + + # Perform a *different* DNS query dig @127.0.0.1 +short ubuntu.com # Observe in the dnsmasq logs that it crashes. Jan 03 13:58:22 j-dnsmasq-2045570 systemd[1]: dnsmasq.service: Main process exited, code=dumped, status=11/SEGV Jan 03 13:58:22 j-dnsmasq-2045570 systemd[1]: dnsmasq.service: Failed with result 'core-dump'. If it doesn't crash right away, repeat these steps a few times, but using a different domain name each time: - add "nameserver 127.0.0.1" to /etc/resolv.conf - observe that dnsmasq notices the change to the file - perform a query for some random domain using "dig @127.0.0.1 +short <domain-of-your-choosing>" - remove "nameserver" from /etc/resolv.conf, observe that dnsmasq noticed the change - perform a query for another random domain The fixed version from proposed will not crash. [ Where problems could occur ] * Think about what the upload changes in the software. Imagine the change is wrong or breaks something else: how would this show up? * It is assumed that any SRU candidate patch is well-tested before upload and has a low overall risk of regression, but it's important to make the effort to think about what ''could'' happen in the event of a regression. * This must '''never''' be "None" or "Low", or entirely an argument as to why your upload is low risk. * This both shows the SRU team that the risks have been considered, and provides guidance to testers in regression-testing the SRU. [ Other Info ] * Anything else you think is useful to include * Anticipate questions from users, SRU, +1 maintenance, security teams and the Technical Board * and address these questions in advance [ Original description ] upstream discussion: https://lists.thekelleys.org.uk/pipermail/dnsmasq- discuss/2022q3/016563.html in my journal, my dns service crash and restart just after: Dec 04 17:18:38 dnsmasq[199333]: no servers found in /run/NetworkManager/no-stub-resolv.conf, will retry oops report: https://errors.ubuntu.com/oops/29cf5e2e-92b1-11ee-9bdf- fa163ec44ecd ubuntu jammy, dnsmasq-base 2.86-1.1ubuntu0.3 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to dnsmasq in Ubuntu. https://bugs.launchpad.net/bugs/2045570 Title: dnsmasq crash when no servers in resolv.conf Status in dnsmasq package in Ubuntu: Fix Released Status in dnsmasq source package in Jammy: In Progress Bug description: [ Impact ] dnsmasq "keeps an eye" on /etc/resolv.conf, and reloads it whenever the file is updated. When that happens and for some reason there were no "nameserver" declarations in the updated file, dnsmasq can crash. Here is a log of a reproducer: $ dig +short @127.0.0.1 ubuntu.com ;; communications error to 127.0.0.1#53: timed out ;; communications error to 127.0.0.1#53: connection refused ;; communications error to 127.0.0.1#53: connection refused ;; no servers could be reached We can see the startup, then when resolv.conf is read again and no nameservers were found, and the crash: Jan 03 13:57:13 j-dnsmasq-2045570 dnsmasq[1507]: started, version 2.86 cachesize 150 Jan 03 13:57:13 j-dnsmasq-2045570 dnsmasq[1507]: DNS service limited to local subnets Jan 03 13:57:13 j-dnsmasq-2045570 dnsmasq[1507]: compile time options: IPv6 GNU-getopt DBus no-UBus i18n IDN2 DHCP DHCPv6 no-Lua TFTP conntrack ipset auth cryptohash DNSSEC loop-detect inotify dumpfile Jan 03 13:57:13 j-dnsmasq-2045570 dnsmasq[1507]: reading /etc/resolv.conf Jan 03 13:57:13 j-dnsmasq-2045570 dnsmasq[1507]: using nameserver 10.0.100.1#53 Jan 03 13:57:13 j-dnsmasq-2045570 dnsmasq[1507]: read /etc/hosts - 7 addresses Jan 03 13:57:13 j-dnsmasq-2045570 systemd[1]: Started dnsmasq - A lightweight DHCP and caching DNS server. Jan 03 13:58:01 j-dnsmasq-2045570 dnsmasq[1507]: no servers found in /etc/resolv.conf, will retry Jan 03 13:58:22 j-dnsmasq-2045570 systemd[1]: dnsmasq.service: Main process exited, code=dumped, status=11/SEGV Jan 03 13:58:22 j-dnsmasq-2045570 systemd[1]: dnsmasq.service: Failed with result 'core-dump'. dnsmasq has provisions for this situation, we can see that in the 13:58:01 message where it says it will retry, but due to this bug, it crashes instead. [ Test Plan ] It might take a few tries to reproduce the bug, but here is the general outline. Also keep in mind that it's important to use a DNS name that isn't cached already by a previous query. # Create a jammy lxd container lxc launch ubuntu-daily:jammy j-dnsmasq-2045570 # Enter the container lxc shell j-dnsmasq-2045570 # From now on, all commands should be executed in the container. # Install dnsmasq, and disable systemd-resolved apt update && apt install -y dnsmasq # Disable systemd-resolved, and start dnsmasq systemctl disable --now systemd-resolved systemctl enable --now dnsmasq # In one terminal inside the container, watch the dnsmasq logs: journalctl -u dnsmasq.service -f # In another terminal, remove /etc/resolv.conf and create a new one, empty rm /etc/resolv.conf echo "nameserver 1.1.1.1" > /etc/resolv.conf # restart dnsmasq systemctl restart dnsmasq.service # Perform a dns query dig @127.0.0.1 +short linux.com # Comment the namserver directive in resolv.conf echo "#nameserver 1.1.1.1" > /etc/resolv.conf # Observe in the dnsmasq logs that it notices the change with a message like: Jan 03 14:14:51 j-dnsmasq-2045570 dnsmasq[2274]: no servers found in /etc/resolv.conf, will retry # Perform a *different* DNS query dig @127.0.0.1 +short ubuntu.com # Observe in the dnsmasq logs that it crashes. Jan 03 13:58:22 j-dnsmasq-2045570 systemd[1]: dnsmasq.service: Main process exited, code=dumped, status=11/SEGV Jan 03 13:58:22 j-dnsmasq-2045570 systemd[1]: dnsmasq.service: Failed with result 'core-dump'. If it doesn't crash right away, repeat these steps a few times, but using a different domain name each time: - add "nameserver 127.0.0.1" to /etc/resolv.conf - observe that dnsmasq notices the change to the file - perform a query for some random domain using "dig @127.0.0.1 +short <domain-of-your-choosing>" - remove "nameserver" from /etc/resolv.conf, observe that dnsmasq noticed the change - perform a query for another random domain The fixed version from proposed will not crash. [ Where problems could occur ] * Think about what the upload changes in the software. Imagine the change is wrong or breaks something else: how would this show up? * It is assumed that any SRU candidate patch is well-tested before upload and has a low overall risk of regression, but it's important to make the effort to think about what ''could'' happen in the event of a regression. * This must '''never''' be "None" or "Low", or entirely an argument as to why your upload is low risk. * This both shows the SRU team that the risks have been considered, and provides guidance to testers in regression-testing the SRU. [ Other Info ] * Anything else you think is useful to include * Anticipate questions from users, SRU, +1 maintenance, security teams and the Technical Board * and address these questions in advance [ Original description ] upstream discussion: https://lists.thekelleys.org.uk/pipermail/dnsmasq- discuss/2022q3/016563.html in my journal, my dns service crash and restart just after: Dec 04 17:18:38 dnsmasq[199333]: no servers found in /run/NetworkManager/no-stub-resolv.conf, will retry oops report: https://errors.ubuntu.com/oops/29cf5e2e-92b1-11ee-9bdf- fa163ec44ecd ubuntu jammy, dnsmasq-base 2.86-1.1ubuntu0.3 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/2045570/+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
