Public bug reported:

Package:

dnsmasq-base 2.91-0ubuntu0.24.04.1 (noble-updates, phased 10%) Previous working 
version: dnsmasq-base
2.90-2ubuntu0.4 

System: 
sb_release -rd:

No LSB modules are available.
Description:    Linux Mint 22.3
Release:        22.3

uname -a:

Linux lohndirektdb-mint-terminalserver 6.8.0-138-generic #138-Ubuntu SMP
PREEMPT_DYNAMIC Fri Jul 31 22:41:49 UTC 2026 x86_64 x86_64 x86_64
GNU/Linux

What happens: 
The machine is an LTSP server (https://ltsp.org/). 
dnsmasq provides proxy DHCP and TFTP for PXE booting about 50 thin clients 
(enable-tftp, tftp
root=/srv/tftp).
 
After the automatic upgrade to 2.91 the service kept running and kept answering 
DHCP, but it stopped serving TFTP completely.
No client could boot any more. Requests are not answered and nothing at all is 
written to the log — not even an error. 

A curl tftp://127.0.0.1/ltsp/ltsp.ipxe on the machine itself times out just the 
same. 
The process sits in state R and burns CPU continuously: 1h46m of CPU time in 14 
hours of uptime, on a daemon that had served six files.

strace -c -p <pid> attaches and detaches without recording a single
syscall, so it is looping in user space.

perf record shows 100% of samples in one call path below
__libc_start_main.

Restarting the service helps briefly: it served eight more transfers and
then hung the same way, within about two minutes.

What I expected:
 
TFTP keeps working, as it did with 2.90 for years on this machine. 
Timeline from this machine 
2026-09-02 18:12:44 dpkg: upgrade dnsmasq-base 2.90-2ubuntu0.4 -> 
2.91-0ubuntu0.24.04.1
2026-09-02 18:23:25 reboot, dnsmasq starts, "TFTP root is /srv/tftp"
2026-09-02 18:24:54 sent /srv/tftp/ltsp/ltsp.ipxe to 192.168.1.60
2026-09-02 18:24:59 sent /srv/tftp/ltsp/x86_64/vmlinuz to 192.168.1.60
2026-09-02 18:24:59 sent /srv/tftp/ltsp/ltsp.img to 192.168.1.60
2026-09-02 18:25:15 sent /srv/tftp/ltsp/x86_64/initrd.img to 192.168.1.60
-- nothing after this; next morning no client can boot, no log entries at all
2026-09-03 08:41:57 systemctl restart dnsmasq
2026-09-03 08:42:17 sent .../initrd.img to 192.168.1.60 (8th transfer after 
restart)
-- hangs again, process in state R, 90s CPU in 143s wall clock

Possible lead: 
Both times the last file served before the hang was the same 82 MB initrd 
(/srv/tftp/ltsp/x86_64/initrd.img, 82221294
bytes). 
That is well past the 32 MB a classic TFTP transfer covers with 512-byte 
blocks, so the block counter has to wrap. The other files served fine and are 
small (2997 bytes and 172544 bytes). I could not narrow this down further 
because the machine is in production and I had to get the clients booting again 
— so treat it as a hint, not as a diagnosis.

Reproduction (suggested) 
Serve a file larger than 32 MB over dnsmasq’s TFTP and fetch it a few times, 
e.g. with PXE clients or curl tftp://<server> <bigfile>.
Watch the dnsmasq process afterwards: if it stays in state R and burns CPU, it 
will not answer any further TFTP requests.Workaround 

Downgrade and pin: 
apt-get install --allow-downgrades dnsmasq=2.90-2ubuntu0.4 
dnsmasq-base=2.90-2ubuntu0.4
apt-mark hold dnsmasq dnsmasq-base

Since the downgrade the server has been serving PXE boots normally
again; dnsmasq is in state S and has used 27 seconds of CPU over the
same kind of workload that made 2.91 accumulate hours.

** Affects: dnsmasq (Ubuntu)
     Importance: Undecided
         Status: New

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2166312

Title:
  dnsmasq 2.91 stops serving TFTP after a few transfers and spins at
  100% CPU

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/2166312/+subscriptions


-- 
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

Reply via email to