dnsmasq 2.43 introduced a bug where an unknown client attempts to renew a lease causing a segfault. This has potential security implications. A new version upstream (and another for other issues) have been released to resolve this. One of my clients keeps triggering this bug, so I've had to isolate it for the time being.
Justin, do you have a reproducer for this issue? Either a client configuration, packet dump, or similar?
Patrick, can you please bump the package?
Snipped (and MAC address masked slightly) from my syslog:
Jul 20 22:53:34 ansible dnsmasq: DHCPREQUEST(eth1) 10.0.2.4 00:21:e9:44:af:XX
Jul 20 22:53:34 ansible dnsmasq: DHCPNAK(eth1) 10.0.2.4 00:21:e9:44:af:XX wrong address
Jul 20 22:53:37 ansible dnsmasq: segfault at 10 ip 0805d69d sp bf8cc7e8 error 4 in dnsmasq[8048000+22000]
Jul 20 22:53:37 ansible dnsmasq: DHCPDISCOVER(eth1) 00:21:e9:44:af:XX
Jul 20 22:53:37 ansible dnsmasq: DHCPOFFER(eth1) 10.0.0.86 00:21:e9:44:af:XX
Jul 20 22:53:37 ansible dnsmasq: DHCPREQUEST(eth1) 10.0.2.4 00:21:e9:44:af:XX
Jul 20 22:53:37 ansible dnsmasq: DHCPNAK(eth1) 10.0.2.4 00:21:e9:44:af:XX wrong network
I setup a NAT on my MacBook Pro (OS X) for the wireless and connected my iPhone to it, it was given a lease of 10.0.2.4. Then I connected to an AP on my dnsmasq-powered network and it attempts to acquire that lease (from a network range that dnsmasq doesn't deal with). dnsmasq isn't a fan and segfaults. My iPhone seems to be the client that triggers this most often, since it hops around so many networks throughout the day.
If you'd really like my config file, let me know and I'll attach an unmangled copy, but I have some public IPs in there so I'm in no rush to publicize them. If you don't mind an altered configuration, I can just mask the public IPs.
net-dns/dnsmasq-2.45 is now in the portage tree
Arches, please test and mark stable:
Target keywords : "alpha amd64 arm hppa ia64 ppc ppc64 s390 sh sparc x86"
Stable AMD64 keyword for 2.45; tested on hardened Opteron 2218 and Core 2 Duo systems.
Stable for HPPA.
This issue looks similar to CVE-2008-3214, which was assigned to dnsmasq 2.25. A reproducer created by Jamie Strandboge  for that older version will also crash 2.43. Earlier versions are unaffected, and so is 2.44.
GLSA vote: YES
I have the same problem on gentoo hardened, and following lines in /var/log/grsec.log
Jul 23 16:18:16 agryf grsec: signal 11 sent to /usr/sbin/dnsmasq[dnsmasq:25473] uid/euid:65534/65534 gid/egid:65534/65534, parent /sbin/init[init:1] uid/euid:0/0 gid/egid:0/0
Jul 24 05:12:15 agryf grsec: From 10.103.30.100: signal 11 sent to /usr/sbin/dnsmasq[dnsmasq:28201] uid/euid:65534/65534 gid/egid:65534/65534, parent /sbin/init[init:1] uid/euid:0/0 gid/egid:0/0
After moving to recent 2.45 version by simply renaming ebuild file :) problem seems to go away.
Maybe 2.43 should be masked before 2.45 approval?
Filip, it does not need to be masked since a later stable version is available. You should "emerge --sync" and update to that. Marking of a vulnerable version will be done via a GLSA and your local tools.
dnsmasq 2.43 allows remote attackers to cause a denial of service (daemon
crash) by (1) sending a DHCPINFORM while lacking a DHCP lease, or (2)
attempting to renew a nonexistent DHCP lease for an invalid subnet as an
"unknown client," a different vulnerability than CVE-2008-3214.
I'll take the lack of an answer as a YES and filed a request together with bug 231282.