| 2023-12-04 15:04:48 |
Alfred |
bug |
|
|
added bug |
| 2023-12-04 15:10:19 |
Alfred |
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 |
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 |
|
| 2023-12-05 18:59:55 |
Lucas Kanashiro |
dnsmasq (Ubuntu): status |
New |
Triaged |
|
| 2023-12-05 19:00:10 |
Lucas Kanashiro |
bug |
|
|
added subscriber Ubuntu Server |
| 2023-12-05 19:01:27 |
Lucas Kanashiro |
tags |
|
server-todo |
|
| 2023-12-05 19:01:35 |
Lucas Kanashiro |
nominated for series |
|
Ubuntu Jammy |
|
| 2023-12-05 19:01:35 |
Lucas Kanashiro |
bug task added |
|
dnsmasq (Ubuntu Jammy) |
|
| 2023-12-05 19:01:42 |
Lucas Kanashiro |
dnsmasq (Ubuntu Jammy): status |
New |
Triaged |
|
| 2023-12-05 19:01:46 |
Lucas Kanashiro |
dnsmasq (Ubuntu): status |
Triaged |
Fix Released |
|
| 2023-12-06 16:12:04 |
Andreas Hasenack |
dnsmasq (Ubuntu Jammy): assignee |
|
Andreas Hasenack (ahasenack) |
|
| 2024-01-03 13:59:16 |
Andreas Hasenack |
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 |
[ Impact ]
* An explanation of the effects of the bug on users and
* justification for backporting the fix to the stable release.
* In addition, it is helpful, but not required, to include an
explanation of how the upload fixes this bug.
[ Test Plan ]
* detailed instructions how to reproduce the bug
* 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.
* if other testing is appropriate to perform before landing this update,
this should also be described here.
[ 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 |
|
| 2024-01-03 13:59:20 |
Andreas Hasenack |
dnsmasq (Ubuntu Jammy): status |
Triaged |
In Progress |
|
| 2024-01-03 14:03:30 |
Andreas Hasenack |
description |
[ Impact ]
* An explanation of the effects of the bug on users and
* justification for backporting the fix to the stable release.
* In addition, it is helpful, but not required, to include an
explanation of how the upload fixes this bug.
[ Test Plan ]
* detailed instructions how to reproduce the bug
* 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.
* if other testing is appropriate to perform before landing this update,
this should also be described here.
[ 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 |
[ 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 ]
* detailed instructions how to reproduce the bug
* 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.
* if other testing is appropriate to perform before landing this update,
this should also be described here.
[ 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 |
|
| 2024-01-03 14:11:19 |
Andreas Hasenack |
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 ]
* detailed instructions how to reproduce the bug
* 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.
* if other testing is appropriate to perform before landing this update,
this should also be described here.
[ 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 |
[ 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
# 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 |
|
| 2024-01-03 14:15:32 |
Andreas Hasenack |
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
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 |
[ 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
# 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 |
|
| 2024-01-03 14:18:10 |
Andreas Hasenack |
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
# 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 |
[ 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 |
|
| 2024-01-03 14:36:52 |
Andreas Hasenack |
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 |
[ 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.
The problem was introduced[1] in version 2.86, and fixed in 2.87, so only jammy is affected.
1. https://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=patch;h=d290630d31f4517ab26392d00753d1397f9a4114;hp=d2ad5dc073aaacaf22b117f16106282a73586803
The commit message says:
"""
This problem was introduced in 2.86.
"""
And indeed, I wasn't able to crash 2.80 shipped in focal.
[ 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 |
|
| 2024-01-03 14:45:41 |
Andreas Hasenack |
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.
The problem was introduced[1] in version 2.86, and fixed in 2.87, so only jammy is affected.
1. https://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=patch;h=d290630d31f4517ab26392d00753d1397f9a4114;hp=d2ad5dc073aaacaf22b117f16106282a73586803
The commit message says:
"""
This problem was introduced in 2.86.
"""
And indeed, I wasn't able to crash 2.80 shipped in focal.
[ 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 |
[ 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.
The problem was introduced[1] in version 2.86, and fixed in 2.87, so only jammy is affected.
1. https://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=patch;h=d290630d31f4517ab26392d00753d1397f9a4114;hp=d2ad5dc073aaacaf22b117f16106282a73586803
The commit message says:
"""
This problem was introduced in 2.86.
"""
And indeed, I wasn't able to crash 2.80 shipped in focal.
[ 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 ]
This is doing some pointer/memory manipulation that could introduce memory leaks or other crashes. In fact, this is exactly what happened in the 2.86 release, which, and I quote, "Major rewrite of the DNS server and domain handling code. This should be largely transparent, but it drastically improves performance and reduces memory foot-print"[2]. 2.88 was then released with the fix used in this SRU (the commit is also in the 2.87 tag, but the upstream release notes only mention it in 2.88).
2. https://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=blob;f=CHANGELOG;h=2ce53a81079810ae43588607f43851dabb5db38d;hb=HEAD#l224
[ Other Info ]
Not at this time.
[ 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 |
|
| 2024-01-03 16:47:35 |
Andreas Hasenack |
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.
The problem was introduced[1] in version 2.86, and fixed in 2.87, so only jammy is affected.
1. https://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=patch;h=d290630d31f4517ab26392d00753d1397f9a4114;hp=d2ad5dc073aaacaf22b117f16106282a73586803
The commit message says:
"""
This problem was introduced in 2.86.
"""
And indeed, I wasn't able to crash 2.80 shipped in focal.
[ 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 ]
This is doing some pointer/memory manipulation that could introduce memory leaks or other crashes. In fact, this is exactly what happened in the 2.86 release, which, and I quote, "Major rewrite of the DNS server and domain handling code. This should be largely transparent, but it drastically improves performance and reduces memory foot-print"[2]. 2.88 was then released with the fix used in this SRU (the commit is also in the 2.87 tag, but the upstream release notes only mention it in 2.88).
2. https://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=blob;f=CHANGELOG;h=2ce53a81079810ae43588607f43851dabb5db38d;hb=HEAD#l224
[ Other Info ]
Not at this time.
[ 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 |
[ 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.
The problem was introduced[1] in version 2.86, and fixed in 2.87, so only jammy is affected.
1. https://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=patch;h=d290630d31f4517ab26392d00753d1397f9a4114;hp=d2ad5dc073aaacaf22b117f16106282a73586803
The commit message says:
"""
This problem was introduced in 2.86.
"""
And indeed, I wasn't able to crash 2.80 shipped in focal.
[ 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. That last query with no "nameserver" lines in resolv.conf won't work, but it won't crash the server.
[ Where problems could occur ]
This is doing some pointer/memory manipulation that could introduce memory leaks or other crashes. In fact, this is exactly what happened in the 2.86 release, which, and I quote, "Major rewrite of the DNS server and domain handling code. This should be largely transparent, but it drastically improves performance and reduces memory foot-print"[2]. 2.88 was then released with the fix used in this SRU (the commit is also in the 2.87 tag, but the upstream release notes only mention it in 2.88).
2. https://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=blob;f=CHANGELOG;h=2ce53a81079810ae43588607f43851dabb5db38d;hb=HEAD#l224
[ Other Info ]
Not at this time.
[ 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 |
|
| 2024-01-10 12:25:56 |
Andreas Hasenack |
merge proposal linked |
|
https://code.launchpad.net/~ahasenack/ubuntu/+source/dnsmasq/+git/dnsmasq/+merge/457905 |
|
| 2024-01-10 15:43:14 |
Ubuntu Archive Robot |
bug |
|
|
added subscriber Andreas Hasenack |
| 2024-01-20 00:12:52 |
Steve Langasek |
dnsmasq (Ubuntu Jammy): status |
In Progress |
Fix Committed |
|
| 2024-01-20 00:12:53 |
Steve Langasek |
bug |
|
|
added subscriber Ubuntu Stable Release Updates Team |
| 2024-01-20 00:13:07 |
Steve Langasek |
bug |
|
|
added subscriber SRU Verification |
| 2024-01-20 00:13:12 |
Steve Langasek |
tags |
server-todo |
server-todo verification-needed verification-needed-jammy |
|
| 2024-01-23 18:33:04 |
Andreas Hasenack |
tags |
server-todo verification-needed verification-needed-jammy |
server-todo verification-done-jammy verification-needed |
|
| 2024-01-31 08:39:04 |
Bryce Harrington |
tags |
server-todo verification-done-jammy verification-needed |
server-todo verification-done verification-done-jammy |
|
| 2024-01-31 17:13:07 |
Launchpad Janitor |
dnsmasq (Ubuntu Jammy): status |
Fix Committed |
Fix Released |
|
| 2024-01-31 17:13:17 |
Robie Basak |
removed subscriber Ubuntu Stable Release Updates Team |
|
|
|
