A flow has been identified into dnssec.c library, causing an infinite loop to dnsmasq service. An attacker who controls any DNSSEC-signed zone can hang the dnsmasq process with a single crafted response, killing all DNS resolution for its clients.
This vulnerability allows remote attackers to create a denial-of-service condition on affected installations of dnsmasq. Authentication is not required to exploit this vulnerability. The ZDI has assigned a CVSS rating of 7.5. The following CVEs are assigned: CVE-2026-4890.
This vulnerability allows remote attackers to create a denial-of-service condition on affected installations of dnsmasq. Authentication is not required to exploit this vulnerability. The ZDI has assigned a CVSS rating of 7.5. The following CVEs are assigned: CVE-2026-4890.
This vulnerability allows remote attackers to execute arbitrary code on affected installations of dnsmasq. Authentication is not required to exploit this vulnerability. The ZDI has assigned a CVSS rating of 8.1. The following CVEs are assigned: CVE-2026-2291.
A flaw was found in dnsmasq before version 2.83. When receiving a query, dnsmasq does not check for an existing pending request for the same name and forwards a new request. By default, a maximum of 150 pending queries can be sent to upstream servers, so there can be at most 150 queries for the same name. This flaw allows an off-path attacker on the network to substantially reduce the number of attempts that it would have to perform to forge a reply and have it accepted by dnsmasq. This issue is mentioned in the "Birthday Attacks" section of RFC5452. If chained with CVE-2020-25684, the attack complexity of a successful attack is reduced. The highest threat from this vulnerability is to data integrity.
A flaw was found in dnsmasq before version 2.83. When getting a reply from a forwarded query, dnsmasq checks in forward.c:replyquery(), which is the forwarded query that matches the reply, by only using a weak hash of the query name. Due to the weak hash (CRC32 when dnsmasq is compiled without DNSSEC, SHA-1 when it is) this flaw allows an off-path attacker to find several different domains all having the same hash, substantially reducing the number of attempts they would have to perform to forge a reply and get it accepted by dnsmasq. This is in contrast with RFC5452, which specifies that the query name is one of the attributes of a query that must be used to match a reply. This flaw could be abused to perform a DNS Cache Poisoning attack. If chained with CVE-2020-25684 the attack complexity of a successful attack is reduced. The highest threat from this vulnerability is to data integrity.
A flaw was found in dnsmasq before version 2.83. A heap-based buffer overflow was discovered in dnsmasq when DNSSEC is enabled and before it validates the received DNS entries. This flaw allows a remote attacker, who can create valid DNS replies, to cause an overflow in a heap-allocated memory. This flaw is caused by the lack of length checks in rfc1035.c:extractname(), which could be abused to make the code execute memcpy() with a negative size in sortrrset() and cause a crash in dnsmasq, resulting in a denial of service. The highest threat from this vulnerability is to system availability.
A flaw was found in dnsmasq before version 2.83. A heap-based buffer overflow was discovered in dnsmasq when DNSSEC is enabled and before it validates the received DNS entries. A remote attacker, who can create valid DNS replies, could use this flaw to cause an overflow in a heap-allocated memory. This flaw is caused by the lack of length checks in rfc1035.c:extractname(), which could be abused to make the code execute memcpy() with a negative size in getrdata() and cause a crash in dnsmasq, resulting in a denial of service. The highest threat from this vulnerability is to system availability.
A flaw was found in dnsmasq before version 2.83. When getting a reply from a forwarded query, dnsmasq checks in the forward.c:replyquery() if the reply destination address/port is used by the pending forwarded queries. However, it does not use the address/port to retrieve the exact forwarded query, substantially reducing the number of attempts an attacker on the network would have to perform to forge a reply and get it accepted by dnsmasq. This issue contrasts with RFC5452, which specifies a query's attributes that all must be used to match a reply. This flaw allows an attacker to perform a DNS Cache Poisoning attack. If chained with CVE-2020-25685 or CVE-2020-25686, the attack complexity of a successful attack is reduced. The highest threat from this vulnerability is to data integrity.
A flaw was found in dnsmasq before version 2.83. A heap-based buffer overflow was discovered in the way RRSets are sorted before validating with DNSSEC data. An attacker on the network, who can forge DNS replies such as that they are accepted as valid, could use this flaw to cause a buffer overflow with arbitrary data in a heap memory segment, possibly executing code on the machine. The highest threat from this vulnerability is to data confidentiality and integrity as well as system availability.
A buffer overflow vulnerability was discovered in the way dnsmasq extract names from DNS packets before validating them with DNSSEC data. An attacker, who can create valid DNS replies, could use this flaw to cause an overflow with arbitrary data in a heap-allocated memory, possibly executing code on the machine. The flaw is in rfc1035.c:extractname() function, which writes data to the memory pointed by name assuming MAXDNAME2 bytes are available in the buffer. However, in some code execution paths it is possible extractname() gets passed an offset from the base buffer, thus reducing in practice the number of available bytes that can be written in the buffer.
Certain DNSSEC aspects of the DNS protocol (in RFC 4033, 4034, 4035, 6840, and related RFCs) allow remote attackers to cause a denial of service (CPU consumption) via one or more DNSSEC responses, aka the "KeyTrap" issue. One of the concerns is that, when there is a zone with many DNSKEY and RRSIG records, the protocol specification implies that an algorithm must evaluate all combinations of DNSKEY and RRSIG records.
A vulnerability was found in dnsmasq before version 2.81, where the memory leak allows remote attackers to cause a denial of service (memory consumption) via vectors involving DHCP response creation.
dnsmasq 2.9 is vulnerable to Integer Overflow via forwardquery.
DISPUTED Dnsmasq 2.86 has a heap-based buffer overflow in answerrequest (called from FuzzAnswerTheRequest and fuzzrfc1035.c). NOTE: the vendor's position is that CVE-2021-45951 through CVE-2021-45957 "do not represent real vulnerabilities, to the best of our knowledge."
DISPUTED Dnsmasq 2.86 has a heap-based buffer overflow in printmac (called from logpacket and dhcpreply). NOTE: the vendor's position is that CVE-2021-45951 through CVE-2021-45957 "do not represent real vulnerabilities, to the best of our knowledge."
DISPUTED Dnsmasq 2.86 has a heap-based buffer overflow in extractname (called from answerauth and FuzzAuth). NOTE: the vendor's position is that CVE-2021-45951 through CVE-2021-45957 "do not represent real vulnerabilities, to the best of our knowledge."
DISPUTED Dnsmasq 2.86 has a heap-based buffer overflow in resizepacket (called from FuzzResizePacket and fuzzrfc1035.c) because of the lack of a proper bounds check upon pseudo header re-insertion. NOTE: the vendor's position is that CVE-2021-45951 through CVE-2021-45957 "do not represent real vulnerabilities, to the best of our knowledge." However, a contributor states that a security patch (mentioned in 016162.html) is needed.
DISPUTED Dnsmasq 2.86 has a heap-based buffer overflow in extractname (called from hashquestions and fuzzutil.c). NOTE: the vendor's position is that CVE-2021-45951 through CVE-2021-45957 "do not represent real vulnerabilities, to the best of our knowledge."
DISPUTED Dnsmasq 2.86 has a heap-based buffer overflow in dhcpreply (called from dhcppacket and FuzzDhcp). NOTE: the vendor's position is that CVE-2021-45951 through CVE-2021-45957 "do not represent real vulnerabilities, to the best of our knowledge."
DISPUTED Dnsmasq 2.86 has a heap-based buffer overflow in checkbadaddress (called from checkforboguswildcard and FuzzCheckForBogusWildcard). NOTE: the vendor's position is that CVE-2021-45951 through CVE-2021-45957 "do not represent real vulnerabilities, to the best of our knowledge."
Integer underflow in the addpseudoheader function in dnsmasq before 2.78 , when the --add-mac, --add-cpe-id or --add-subnet option is specified, allows remote attackers to cause a denial of service via a crafted DNS request.
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.
dnsmasq 2.25 allows remote attackers to cause a denial of service (daemon crash) by (1) renewing a nonexistent lease or (2) sending a DHCPREQUEST for an IP address that is not in the same network, related to the DHCP NAK response from the daemon.
Core Security Technologies discovered a heap overflow vulnerability in dnsmasq when the TFTP service is enabled ('--enable-tftp'). If the configured tftp-prefix is sufficiently long, and a remote user sent a request which sends a long file name, dnsmasq could crash or, possibly, execute arbitrary code with root privileges.
The default tftp-prefix is /var/tftpd, which is short enough to make this difficult to exploit; if a longer prefix is used then arbitrary code execution may be possible. As well, Red Hat does not have TFTP support enabled by default.
The tftprequest function in tftp.c in dnsmasq before 2.50, when --enable-tftp is used, allows remote attackers to cause a denial of service (NULL pointer dereference and daemon crash) via a TFTP read (aka RRQ) request with a malformed blksize option.
Description of problem: On my workstation, as a virtual machine host, I have NetworkManager's dnsmasq configured to forward DNS queries for a local domain to 192.168.122.1, so I can resolve those to virtual machine DHCP hostnames. Recently this stopped working.
With manual dig commands, I found that TCP queries still work, but UDP doesn't. For example, in libvirt I have a statically defined name "vhost" to 192.168.122.1 itself. From the host, the command "dig +short +tcp @192.168.122.1 vhost" resolves that just fine. But "dig +short +notcp @192.168.122.1 vhost" says "connection timed out; no servers could be reached". From a guest, +tcp and +notcp both work fine.
Version-Release number of selected component (if applicable): libvirt-0.9.11.8-2.fc17.x8664, dnsmasq-2.63-1.fc17.x8664 I also tried dnsmasq-2.65-1.fc17.x8664 from updates-testing
How reproducible: 100%
Steps to Reproduce: 1. From the virtual machine host, try to query the libvirt dnsmasq. Actual results: $ dig +short +tcp @192.168.122.1 vhost 192.168.122.1 $ dig +short +notcp @192.168.122.1 vhost ;; connection timed out; no servers could be reached
Expected results: A positive answer from both TCP and UDP queries.
Additional info: I suspect this is related to the fixes for CVE-2012-3411, but it seems weird that UDP and TCP would be treated differently.
Dnsmasq before 2.76 allows remote servers to cause a denial of service (crash) via a reply with an empty DNS address that has an (1) A or (2) AAAA record defined locally.
The tcprequest function in Dnsmasq before 2.73rc4 does not properly handle the return value of the setupreply function, which allows remote attackers to read process memory and cause a denial of service (out-of-bounds read and crash) via a malformed DNS request.
A vulnerability was found in the implementation of DNSSEC in Dnsmasq up to and including 2.78. Wildcard synthesized NSEC records could be improperly interpreted to prove the non-existence of hostnames that actually exist.