Description of problem:

When a dhcp "hex string" (type 'X') option with a single byte value that is
not NVT-ASCII ( is < 32 or > 127 ) is received by dhcdbd, it could incorrectly
interpret it as an ASCII value, and cause potential memory corruption, as
reported by Florian Hackenberger<florian> as occurring under
valgrind on his Gentoo system:
<
lease {
  interface "eth1";
  fixed-address 192.168.1.3;
  option subnet-mask 255.255.255.0;
  option routers 192.168.1.1;
  option dhcp-lease-time 86400;
  option dhcp-message-type 5;
  option dhcp-server-identifier 192.168.1.1;
  option domain-name-servers 192.168.1.1,0.0.0.0;
  option host-name ff;
  option domain-name "";
  renew 4 2006/4/20 02:30:27;
  rebind 4 2006/4/20 14:11:06;
  expire 4 2006/4/20 17:11:06;
}

Here is the new valgrind output:
hacki-mobile dhcdbd-1.12 # valgrind ./dhcdbd --system -n
...
===21235== Using valgrind-3.1.0, a dynamic binary instrumentation framework.
...
==21235== Syscall param socketcall.sendto(msg) points to uninitialised byte(s)
...
==21235== Syscall param socketcall.sendto(msg) points to uninitialised byte(s)
...
==21235== Invalid read of size 1
==21235==    at 0x401E1F1: strlen 
(in /usr/lib/valgrind/x86-linux/vgpreload_memcheck.so)
==21235==    by 0x40B3C48: vfprintf (in /lib/tls/libc-2.3.6.so)
==21235==    by 0x40CBC2A: vsprintf (in /lib/tls/libc-2.3.6.so)
==21235==    by 0x40B8D3A: sprintf (in /lib/tls/libc-2.3.6.so)
==21235==    by 0x8057D40: dhco_text_from_value (dhcp_options.c:1586)
==21235==    by 0x8058EC1: dhco_output_option (dhcp_options.c:2168)
==21235==    by 0x80526B7: dhcdbd_dhcp_option_handler (dhcdbd.c:2098)
==21235==    by 0x8056A6C: dhco_parse_option_settings (dhcp_options.c:1029)
==21235==    by 0x8052E78: dhcdbd_if_set (dhcdbd.c:2203)
==21235==    by 0x804AB27: message_handler (dbus_service.c:257)
==21235==    by 0x406313A: (within /usr/lib/libdbus-1.so.2.0.0)
==21235==    by 0x4058899: dbus_connection_dispatch 
(in /usr/lib/libdbus-1.so.2.0.0)
==21235==  Address 0x41B7301 is 0 bytes after a block of size 1 alloc'd
==21235==    at 0x401B590: malloc 
(in /usr/lib/valgrind/x86-linux/vgpreload_memcheck.so)
==21235==    by 0x8058B45: dhco_input_option (dhcp_options.c:2043)
==21235==    by 0x80569F4: dhco_parse_option_settings (dhcp_options.c:1018)
==21235==    by 0x8052E78: dhcdbd_if_set (dhcdbd.c:2203)
==21235==    by 0x804AB27: message_handler (dbus_service.c:257)
==21235==    by 0x406313A: (within /usr/lib/libdbus-1.so.2.0.0)
==21235==    by 0x4058899: dbus_connection_dispatch 
(in /usr/lib/libdbus-1.so.2.0.0)
==21235==    by 0x804CE7A: dbus_svc_main_loop (dbus_service.c:1348)
==21235==    by 0x8054B49: dhcdbd_run (dhcdbd.c:2801)
==21235==    by 0x805985D: main (main.c:128)

As you can see, the AP sends ÿ as hostname, which obviously is not what it 
should, however dhcdbd should not crash on weird input.
>

Yes, the dhcp server was sending the single hex byte 0xff as the host-name
option, which caused potential memory corruption in dhcdbd, and several
dhcdbd crashes.

Happily, ISC DHCP 3.0.4b3+ has converted the host-name option type from 'X' 
( hex or ASCII ) to 't' (ASCII only) - this patch has been backported to
Red Hat's DHCP 3.0.1 - 3.0.3 distributions, so dhcp server operators will 
no longer be able to get away with setting the host-name of clients to -1 .

But yes, dhcdbd should not crash if someone sends a hex string value of
a single non-ascii byte - fixed in dhcdbd-1.14+ .


Version-Release number of selected component (if applicable):
dhcdbd-1.12

How reproducible:
100%

Steps to Reproduce:
See above