NLnet Labs ldns 1.2.0 up to and including versions 1.9.0, when used in applications as (stub) resolver over UDP, lacks matching the query destination address and port with the response source address and port. Furthermore not the query ID, neither the question of the query is matched with that of the response. This makes applications, that use ldns for (stub) resolver functionality over UDP, vulnerable for off-path poisoning attacks. The drill tool, which is shipped with ldns, suffers from this vulnerability.

When a zone file in ldns 1.7.1 is parsed, the function ldns_nsec3_salt_data is too trusted for the length value obtained from the zone file. When the memcpy is copied, the 0xfe - ldns_rdf_size(salt_rdf) byte data can be copied, causing heap overflow information leakage.

When ldns version 1.7.1 verifies a zone file, the ldns_rr_new_frm_str_internal function has a heap out of bounds read vulnerability. An attacker can leak information on the heap by constructing a zone file payload.

A double-free vulnerability in str2host.c in ldns 1.7.0 have unspecified impact and attack vectors.

A double-free vulnerability in parse.c in ldns 1.7.0 have unspecified impact and attack vectors.

The ldns-keygen tool in ldns 1.6.x uses the current umask to set the privileges of the private key, which might allow local users to obtain the private key by reading the file.

Heap-based buffer overflow in the ldns_rr_new_frm_str_internal function in ldns before 1.6.11 allows remote attackers to cause a denial of service (crash) and possibly execute arbitrary code via a Resource Record (RR) with an unknown type containing input that is longer than a specified length.

Heap-based buffer overflow in the ldns_rr_new_frm_str_internal function in ldns 1.4.x allows remote attackers to cause a denial of service (memory corruption) and possibly execute arbitrary code via a DNS resource record (RR) with a long (1) class field (clas variable) and possibly (2) TTL field.