Hi all,

I have identified a high-severity heap buffer overflow vulnerability in
src/cache.c. This issue arises from a synchronization failure in the
TCP/DNS pipe communication between the parent and child processes when a
memory allocation fails.
Summary

In cache_recv_insert(), when blockdata_read() fails to allocate memory
(returning NULL), the code uses a continue statement to skip the current
iteration. However, because blockdata_read() returns before consuming the
expected number of bytes from the file descriptor (fd), the unread Resource
Record (RR) data remains in the pipe.

In the next iteration of the loop, this leftover data is incorrectly
interpreted as the length of the next domain name (m), leading to a heap
buffer overflow when reading into daemon->namebuff.
Technical Details

*File:* src/cache.c *Function:* cache_recv_insert() *Impacted Lines:* 1018,
1025, 1032 (in master/2.93test7)

*Vulnerable Logic:*

// src/cache.c:1018if ((flags & F_RR) && !(flags & F_NEG) && (flags & F_KEYTAG)
    && !(block = addr.rrblock.rrdata = blockdata_read(fd,
addr.rrblock.datalen)))
  continue; // BUG: Should be 'return 0' to abort the transaction

When blockdata_read() fails at src/blockdata.c:92 (due to new_block()
returning NULL), it returns NULL without reading any data from the pipe.
The continue statement then forces the loop to start over:

   1.

   The loop tries to read m (the next name length).
   2.

   It instead reads the *first 8 bytes of the unconsumed RR data* as m.
   3.

   If the attacker-controlled RR data results in an m > MAXDNAME (1024),
   the subsequent read_write(fd, daemon->namebuff, m, ..) call overflows
   the daemon->namebuff heap buffer.

Impact

An attacker can trigger this by:

   1.

   Sending a DNS query that generates a large RR response (setting F_RR).
   2.

   Inducing memory pressure (or exploiting a specific allocation limit).
   3.

   Once blockdata_read fails, the pipe desyncs, allowing the attacker to
   control the m value and execute a heap overflow.

This can lead to a *Denial of Service (DoS)* or potentially *Remote Code
Execution (RCE)* under specific memory layouts.

_______________________________________________
Dnsmasq-discuss mailing list
[email protected]
https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss