CVE-2016-9300, CVE-2016-9301, and CVE-2016-9302 are *NOT* valid bug reports.
Here’s the deal: The reporter had to patch MaraDNS before he was able to crash her. The patch, however, treats MaraDNS’ special buffer-overflow-resistant “js_string” as if it were an ordinary string — but it’s not. Here’s the offending code patched in to MaraDNS from the reporter’s “bug report”: sock_num = read(0, incoming, 512); As per the man page for read: ssize_t read(int fd, void *buf, size_t count); DESCRIPTION read() attempts to read up to count bytes from file descriptor fd into the buffer starting at buf. However, incoming is not a raw string buffer: It’s a special js_string object which MaraDNS uses to be buffer overflow resistant, as can be seen here in server/MaraDNS.c: int main(int argc, char **argv) { js_string *mararc_loc = 0, *errors = 0, *bind_address = 0, *ipv6_bind_address = 0, *csv2_synthip_address = 0, *ipv4_bind_address = 0, *incoming = 0, *uncomp = 0, *verbstr = 0; The js_string structure (I guess I would call it an object here in 2016) is defined in libs/JsStr.h: typedef struct { unsigned char *string; /* Actual physical string */ unsigned int unit_size; /* The size of a single character in the string */ unsigned int unit_count; /* The length of the string, in units */ unsigned int max_count; /* The maximum allowable size of the string, also in units */ int encoding; /* The type of language/encoding the string is in */ int is_good; /* This is checked to make sure the data structure is sane */ } js_string; Point being, if we patch MaraDNS to treat this structure as a raw buffer instead of a structure, we will be able to crash MaraDNS — but that doesn’t mean we have found a UDP packet of death which will crash unpatched MaraDNS 2.0.13. I appreciate that people are performing security research with MaraDNS, and the fact that researchers need to resort to patching MaraDNS before crashing her indicates that, a decade and a half later MaraDNS is still a usable DNS server with a strong security record.