+++ This bug was initially created as a clone of Bug #1193801

This is to track finding 2) of the parent bug:

2) TCP Receive Path does not Check for Presence of Sufficient Header Data
=========================================================================

In the UDP server reply code path a literal size check is performed to make
sure that at least a complete DNS header has been received
(`dnsproxy.c:2257`). This check is missing in the TCP server reply code path
as can be seen in:

- dnsproxy.c:2417: here a heap buffer of the exact claimed packet size is
  allocated (this can cause up to a 64 KB buffer to be allocated by the way).
- dnsproxy.c:2444: here the now completely received packet is passed on to
  `forward_dns_reply()` without any further minimum package size checks.

This means that a malicious DNS server can send a minimum reply message
consisting of four bytes (claiming a TCP message of two bytes size, and then
supplying the correct request ID in the next two bytes). `forward_dns_reply()`
will then be called with the `reply_len` parameter being set to 4. There are
no further input size checks in `forward_dns_reply`:

```
int dns_id, sk, err, offset = protocol_offset(protocol);

if (offset < 0)
	return offset;

hdr = (void *)(reply + offset);
```

`offset` will be 2 for the TCP case. Thus `hdr` will point to the two valid
DNS ID bytes at the end of the heap allocated buffer. All further protocol
processing code in this function will operate on undefined out of bounds heap
data.

From here on the characteristics of this vulnerability are similar to issue
1). There can be undefined behaviour and a possiblity for a remote DoS, a heap
based information leak maybe.

To fix this the `tcp_server_event()` function should not call
`forward_dns_reply()` if no complete header has been received. Furthermore an
upper TCP packet size limit (`TCP_MAX_BUF_LEN` already exists) should be
enforced also. The suggestions for issue 1) regarding the
`forward_dns_reply()` function apply here as well.

A sample run with `valgrind` acting against a malicious DNS server showed
output like this:

    Invalid read of size 2
       at 0x487311: forward_dns_reply.isra.0 (dnsproxy.c:2153)
       by 0x487EBD: tcp_server_event (dnsproxy.c:2447)
       by 0x48C0D9E: g_main_context_dispatch (in /usr/lib64/libglib-2.0.so.0.7000.2)
       by 0x48C1127: ??? (in /usr/lib64/libglib-2.0.so.0.7000.2)
       by 0x48C1412: g_main_loop_run (in /usr/lib64/libglib-2.0.so.0.7000.2)
       by 0x41217B: main (main.c:932)
     Address 0x587c88c is 2 bytes after a block of size 10 alloc'd
       at 0x48437B5: malloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
       by 0x48C719F: g_try_malloc (in /usr/lib64/libglib-2.0.so.0.7000.2)
       by 0x4881A9: tcp_server_event (dnsproxy.c:2420)
       by 0x48C0D9E: g_main_context_dispatch (in /usr/lib64/libglib-2.0.so.0.7000.2)
       by 0x48C1127: ??? (in /usr/lib64/libglib-2.0.so.0.7000.2)
       by 0x48C1412: g_main_loop_run (in /usr/lib64/libglib-2.0.so.0.7000.2)
       by 0x41217B: main (main.c:932)