>Number:         12731
>Category:       bin
>Synopsis:       dhcpd coredumps on DHCPDISCOVER with null uid pointer
>Confidential:   no
>Severity:       critical
>Priority:       high
>Responsible:    bin-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Mon Apr 23 20:44:00 PDT 2001
>Closed-Date:
>Last-Modified:
>Originator:     John F. Woods
>Release:        NetBSD-current Mon Apr 23 23:21:46 EDT 2001
>Organization:
Misanthropes-R-Us
>Environment:
	
System: NetBSD jfwhome.funhouse.com 1.5T NetBSD 1.5T (GENERIC) #2: Sun Apr 8 19:14:04 PDT 2001 toddpw@vader.toddpw.net:/usr/src/sys/arch/i386/compile/GENERIC i386
Architecture: i386
Machine: i386
>Description:
    This is similar to, but probably not the same as, bin/12070.

    When any of my Mac OS 9.1 machines contacts the dhcp server on my netbsd
box, dhcpd coredumps.  This is with dhcp sources which are current as of
today, which claim to be dhcp version 3, beta 2, patchlevel 24, April 5,
2001.

The backtrace I get is:

#0  0x807053c in do_hash (name=0x0, len=14, size=9973)
    at /usr/src/usr.sbin/dhcp/omapip/hash.c:170
#1  0x8070840 in hash_lookup (vp=0xbfbfc38c, table=0x811f000,
    name=0x0,
    len=14, file=0x80b8600 "/usr/src/usr.sbin/dhcp/server/mdb.c",
    line=1520)
    at /usr/src/usr.sbin/dhcp/omapip/hash.c:274
#2  0x806d33c in lease_hash_lookup (ptr=0xbfbfc38c, table=0x811f000,
    buf=0x0,
    len=14, file=0x80b8600 "/usr/src/usr.sbin/dhcp/server/mdb.c",
    line=1520)
    at /usr/src/usr.sbin/dhcp/server/mdb.c:1937
#3  0x806c3e7 in find_lease_by_uid (lp=0xbfbfc38c, uid=0x0, len=14,
    file=0x80b8600 "/usr/src/usr.sbin/dhcp/server/mdb.c", line=1520)
    at /usr/src/usr.sbin/dhcp/server/mdb.c:1472
#4  0x806c57b in uid_hash_delete (lease=0x8162000)
    at /usr/src/usr.sbin/dhcp/server/mdb.c:1520
#5  0x80666d7 in dhcp_lease_destroy (h=0x8162000,
    file=0x80b4260 "/usr/src/usr.sbin/dhcp/server/dhcp.c", line=365)
    at /usr/src/usr.sbin/dhcp/server/omapi.c:357
#6  0x807ca5f in omapi_object_dereference (h=0xbfbfc814,
    file=0x80b4260 "/usr/src/usr.sbin/dhcp/server/dhcp.c", line=365)
    at /usr/src/usr.sbin/dhcp/omapip/alloc.c:543
#7  0x806d850 in lease_dereference (ptr=0xbfbfc814,
    file=0x80b4260 "/usr/src/usr.sbin/dhcp/server/dhcp.c", line=365)
    at /usr/src/usr.sbin/dhcp/server/salloc.c:61
#8  0x804c4da in dhcpdiscover (packet=0x811e400, ms_nulltp=0)
    at /usr/src/usr.sbin/dhcp/server/dhcp.c:365
#9  0x804c095 in dhcp (packet=0x811e400)
    at /usr/src/usr.sbin/dhcp/server/dhcp.c:220
#10 0x809260e in do_packet (interface=0x811e300, packet=0xbfbfc904,
    len=346,
    from_port=17408, from={len = 4,
      iabuf = "\000\000\000\000\037\000??\037\000??p_??"},
    hfrom=0xbfbfd920)
    at /usr/src/usr.sbin/dhcp/common/options.c:2164
#11 0x8081c71 in got_one (h=0x811e300)
    at /usr/src/usr.sbin/dhcp/common/discover.c:769
#12 0x8079027 in omapi_one_dispatch (wo=0x0, t=0x0)
    at /usr/src/usr.sbin/dhcp/omapip/dispatch.c:378
#13 0x80803d8 in dispatch () at
    /usr/src/usr.sbin/dhcp/common/dispatch.c:105
#14 0x804af2b in main (argc=2, argv=0xbfbfdb84, envp=0xbfbfdb90)
    at /usr/src/usr.sbin/dhcp/server/dhcpd.c:602
#15 0x8049e79 in ___start ()

The lease structure being examined looks like this:

(gdb) print *lease
$9 = {type = 0x80d9240, refcnt = 0, handle = 0, outer = 0x0, inner = 0x0,
  next = 0x0, n_uid = 0x0, n_hw = 0x0, ip_addr = {len = 4,
    iabuf = "@ }C\004X\006\b4C??@\222\r\b"}, starts = 0, ends = 0,
  timestamp = 988062731, sort_time = 0, client_hostname = 0x0, scope = 0x0,
  host = 0x811e100, subnet = 0x811e000, pool = 0x0, billing_class = 0x0,
  agent_options = 0x0, on_expiry = 0x0, on_commit = 0x0, on_release = 0x0,
  uid = 0x0, uid_len = 14, uid_max = 0, uid_buf = "\000\000\000\000\000\000",
  hardware_addr = {hlen = 7 '\a',
    hbuf = "\001\000\005\002k\220d\000\000\000\000\000\000\000\000\000"},
  flags = 1 '\001', binding_state = 1 '\001', next_binding_state = 0 '\000',
  state = 0x0, tstp = 0, tsfp = 0, cltt = 0, next_pending = 0x0}

Note particularly the null uid field, which is what is being used as the name
field for lease_hash_lookup in stackframe #3.

the packet struct in dhcpdiscover contains
gdb) print *packet
$13 = {raw = 0xbfbfc904, refcnt = 1, packet_length = 346, packet_type = 1,
  options_valid = 1, client_port = 17408, client_addr = {len = 4,
    iabuf = "\000\000\000\000\037\000??\037\000??p_??"},
  interface = 0x811e300, haddr = 0xbfbfd920, circuit_id = 0x0,
  circuit_id_len = 0, remote_id = 0x0, remote_id_len = 0,
  got_requested_address = 0, shared_network = 0x80d9640, options = 0x80d9880,
  class_count = 0, classes = {0x0, 0x0, 0x0, 0x0, 0x0}, known = 1,
  authenticated = 0}

And here is the raw dhcp packet:

(gdb) print *packet->raw
$17 = {op = 1 '\001', htype = 1 '\001', hlen = 6 '\006', hops = 0 '\000',
  xid = 1260128951, secs = 0, flags = 0, ciaddr = {s_addr = 0}, yiaddr = {
    s_addr = 0}, siaddr = {s_addr = 0}, giaddr = {s_addr = 0},
  chaddr = "\000\005\002k\220d\000\000\000\000\000\000\000\000\000",
  sname = '\000' <repeats 63 times>, file = '\000' <repeats 127 times>,
  options = "c\202Sc5\001\0017\020\001\003\006\017!*,-./EFGJNO9\002\005\3\004
\a\000millan</Mac OS 9.1 Open Transport 2.7.5 Power Macintosh\f\016babs' compu
ter000\000\000\000\000\000\000\000\000\00004\b\00004\b\000\005\000\000\000\000
\020\000\000\001\000\000\000@4\b\000@D\b\000@D\b\000l8\000\000`x\000\000\006\000
\000\000\000\020\000\000\002\000\000\000,m\b\000,}\b\000,}\b\000\200\000\000\000
\200\000\000\000\006\000\000\000\004\000\000\000"...}

"millan" is the dhcp identifier I've told the Mac to use (and it is the
hostname associated with the IP address the Mac will be assigned); "babs' computer" is the Appletalk name for the computer.

>How-To-Repeat:
	I have a core dump and matching debuggable executable available.
If I get time, I will attempt to narrow down the problem further.  It is
very readily repeatable for me (i.e. every single time).

>Fix:
	
>Release-Note:
>Audit-Trail:
>Unformatted: