An issue was discovered in adns before 1.5.2. pap_mailbox822 does not properly check st from adns__findlabel_next. Without this, an uninitialised stack value can be used as the first label length. Depending on the circumstances, an attacker might be able to trick adns into crashing the calling program, leaking aspects of the contents of some of its memory, causing it to allocate lots of memory, or perhaps overrunning a buffer. This is only possible with applications which make non-raw queries for SOA or RP records.

An issue was discovered in adns before 1.5.2. It hangs, eating CPU, if a compression pointer loop is encountered.

An issue was discovered in adns before 1.5.2. It corrupts a pointer when a nameserver speaks first because of a wrong number of pointer dereferences. This bug may well be exploitable as a remote code execution.

An issue was discovered in adns before 1.5.2. adns_rr_info mishandles a bogus *datap. The general pattern for formatting integers is to sprintf into a fixed-size buffer. This is correct if the input is in the right range; if it isn't, the buffer may be overrun (depending on the sizes of the types on the current platform). Of course the inputs ought to be right. And there are pointers in there too, so perhaps one could say that the caller ought to check these things. It may be better to require the caller to make the pointer structure right, but to have the code here be defensive about (and tolerate with an error but without crashing) out-of-range integer values. So: it should defend each of these integer conversion sites with a check for the actual permitted range, and return adns_s_invaliddata if not. The lack of this check causes the SOA sign extension bug to be a serious security problem: the sign extended SOA value is out of range, and overruns the buffer when reconverted. This is related to sign extending SOA 32-bit integer fields, and use of a signed data type.

An issue was discovered in adns before 1.5.2. It overruns reading a buffer if a domain ends with backslash. If the query domain ended with \, and adns_qf_quoteok_query was specified, qdparselabel would read additional bytes from the buffer and try to treat them as the escape sequence. It would depart the input buffer and start processing many bytes of arbitrary heap data as if it were the query domain. Eventually it would run out of input or find some other kind of error, and declare the query domain invalid. But before then it might outrun available memory and crash. In principle this could be a denial of service attack.

An issue was discovered in adns before 1.5.2. adnshost mishandles a missing final newline on a stdin read. It is wrong to increment used as well as setting r, since used is incremented according to r, later. Rather one should be doing what read() would have done. Without this fix, adnshost may read and process one byte beyond the buffer, perhaps crashing or perhaps somehow leaking the value of that byte.

An issue was discovered in adns before 1.5.2. It fails to ignore apparent answers before the first RR that was found the first time. when this is fixed, the second answer scan finds the same RRs at the first. Otherwise, adns can be confused by interleaving answers for the CNAME target, with the CNAME itself. In that case the answer data structure (on the heap) can be overrun. With this fixed, it prefers to look only at the answer RRs which come after the CNAME, which is at least arguably correct.