mirror of
http://thekelleys.org.uk/git/dnsmasq.git
synced 2026-10-18 11:09:36 +00:00
3ea905b98b8756f0652a9626a98384e96bab3a97
In log6_opts(), the OPTION6_STATUS_CODE branch did: memcpy(daemon->namebuff + len, opt6_ptr(opt, 2), opt6_len(opt)-2); daemon->namebuff[len + opt6_len(opt) - 2] = 0; Two bugs: 1. Integer underflow: if opt6_len(opt) < 2, the subtraction wraps to a huge size_t, making memcpy write gigabytes and crash with SIGSEGV. 2. Heap overflow: no upper-bound check. opt6_len() can return up to 65535, but daemon->namebuff is only (MAXDNAME*2)+1 = 2051 bytes. A STATUS_CODE payload larger than ~2045 bytes would overflow the heap buffer. Exploitability: log6_opts() is only ever called on daemon->outpacket, the outgoing DHCPv6 reply built by dnsmasq itself — NOT on incoming client packets. Consequently, these bugs are NOT directly triggerable by a remote attacker under the current code. The fix is defensive: put_opt6_short() (which writes STATUS_CODE options in outgoing packets) always produces opt6_len >= 2, so neither bug fires in practice today. However, the unchecked arithmetic is a latent hazard that could become exploitable if future refactoring passes incoming option data through log6_opts(): - Guard the block with opt6_len(opt) >= 2 to prevent underflow. - Cap slen to the remaining space in daemon->namebuff. Signed-off-by: Dominik <dl6er@dl6er.de>
Languages
C
94.3%
Perl
2.2%
HTML
1.2%
Shell
1%
Makefile
0.6%
Other
0.6%