On dnsmasq 2.92, a server-facing BOOTREPLY processed under --dhcp-split-relay can place OPTION_AGENT_ID 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 OPTION_AGENT_ID, dnsmasq sets *opt = OPTION_END and then executes memset(opt + 1, 0, option_len(opt) + 2). The attached PoC uses the smallest RFC 3046-conformant Agent Information option: OPTION_AGENT_ID, 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 recv_dhcp_packet() grows the receive iovec to the packet length in src/dhcp-common.c:54-64, and expand_buf() reallocates that exact size in src/util.c:703-716.