CVE-2026-6507: Dnsmasq: dnsmasq: denial of service due to out-of-bounds write in dhcp bootreply processing

On dnsmasq 2.92, a server-facing BOOTREPLY processed under --dhcp-split-relay can place OPTIONAGENTID at the end of a 552-byte packet and make dnsmasq zero one byte past the receive buffer. In my PoC, a benign 552-byte BOOTREPLY leaves the daemon alive, while the malicious variant followed by one oversized BOOTREPLY aborts the normal build with malloc(): invalid next size (unsorted). The attached PoC also reproduces the direct AddressSanitizer report at src/rfc2131.c:3251.

Details The bug is in src/rfc2131.c:3249-3251. After finding OPTIONAGENTID, dnsmasq sets opt = OPTIONEND and then executes memset(opt + 1, 0, optionlen(opt) + 2). The attached PoC uses the smallest RFC 3046-conformant Agent Information option: OPTIONAGENTID, length 2, followed by one zero-length sub-option (01 00). When that option starts at byte 548 of a 552-byte BOOTREPLY, memset(opt + 1, 0, 4) clears bytes 549..552, so the last byte is still written one byte past the end of the packet buffer. The buffer is exact-size because recvdhcppacket() grows the receive iovec to the packet length in src/dhcp-common.c:54-64, and expandbuf() reallocates that exact size in src/util.c:703-716.

— Red Hat