In some cases, DUID will change for the same machine during network
boot. Support assigning small blocks of IPv6 addresses to work around
changing DUID.
Quick made support of SO_TIMESTAMP is broken and it broke whole DHCP.
Until that is fixed and properly tested, remove its support. Just skip
call to unsupported ioctl.
Signed-off-by: Petr Menšík <pemensik@redhat.com>
- Stop using nettle_hashes directly, use access function (#1548060)
- Do not break on cname with spaces (#1498667)
Signed-off-by: Petr Menšík <pemensik@redhat.com>
None of currently supported distributions need that.
Last one was EL5 which is EOL for a while.
Signed-off-by: Igor Gnatenko <ignatenkobrain@fedoraproject.org>
None of currently supported distributions need that.
It was needed last for EL5 which is EOL now
Signed-off-by: Igor Gnatenko <ignatenkobrain@fedoraproject.org>
We define some constants in dnsmasq.h, which have an influence on
stdio.h. So do not include stdio.h before dnsmasq.h.
Signed-off-by: Petr Menšík <pemensik@redhat.com>
Further fix to 0549c73b7ea6b22a3c49beb4d432f185a81efcbc
Handles case when RR name is not a pointer to the question,
only occurs for some auth-mode replies, therefore not
detected by fuzzing (?)
Signed-off-by: Petr Menšík <pemensik@redhat.com>
creation.
Fix out-of-memory Dos vulnerability. An attacker which can
send malicious DNS queries to dnsmasq can trigger memory
allocations in the add_pseudoheader function
The allocated memory is never freed which leads to a DoS
through memory exhaustion. dnsmasq is vulnerable only
if one of the following option is specified:
--add-mac, --add-cpe-id or --add-subnet.
Signed-off-by: Petr Menšík <pemensik@redhat.com>
Fix DoS in DNS. Invalid boundary checks in the
add_pseudoheader function allows a memcpy call with negative
size An attacker which can send malicious DNS queries
to dnsmasq can trigger a DoS remotely.
dnsmasq is vulnerable only if one of the following option is
specified: --add-mac, --add-cpe-id or --add-subnet.
Signed-off-by: Petr Menšík <pemensik@redhat.com>
Fix information leak in DHCPv6. A crafted DHCPv6 packet can
cause dnsmasq to forward memory from outside the packet
buffer to a DHCPv6 server when acting as a relay.
Signed-off-by: Petr Menšík <pemensik@redhat.com>
