Bug 393 - smbd coredump when client uses netbios name
smbd coredump when client uses netbios name
Product: Samba 3.0
Classification: Unclassified
Component: File Services
All Linux
: P2 enhancement
: none
Assigned To: Gerald (Jerry) Carter
Depends on:
  Show dependency treegraph
Reported: 2003-09-02 14:43 UTC by Ron Bhanukitsiri
Modified: 2005-11-14 09:29 UTC (History)
1 user (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Ron Bhanukitsiri 2003-09-02 14:43:11 UTC
When mapping a drive from Windows 2000 Professional with SP3, using netbios name
causes smbd to coredump (eg. net use f: \\server\rondrive).  However, using
fully qualified DNS name (eg. net use f: \\server.domain.com\rondrive) works 
fine.  smbd is running on Red Hat Linux 7.3.

Here's the stack trace.
#0  0x40261fa1 in kill () from /lib/libc.so.6
(gdb) where
#0  0x40261fa1 in kill () from /lib/libc.so.6
#1  0x40261d99 in raise () from /lib/libc.so.6
#2  0x40263264 in abort () from /lib/libc.so.6
#3  0x0818abcf in smb_panic () at lib/util.c:1483
#4  0x0817afc6 in fault_report (sig=11) at lib/fault.c:41
#5  <signal handler called>
#6  0x4006de2a in krb5_free_ticket () from /usr/kerberos/lib/libkrb5.so.3
#7  0x081d8d6a in ads_verify_ticket (realm=0x8359f38 "SOHO.IXTLANET.COM", 
    ticket=0xbfffeb40, principal=0xbfffead4, auth_data=0xbfffeb30, 
    ap_rep=0xbfffeb20, session_key=0xbfffeaf0 "¨®5\bûêÿ¿L")
    at libads/kerberos_verify.c:242
#8  0x0809f56e in reply_spnego_kerberos (conn=0x0, inbuf=0x4040a008 "", 
    outbuf=0x4042b008 "", length=1390, bufsize=131072, secblob=0xbfffebb0)
    at smbd/sesssetup.c:167
#9  0x0809fd80 in reply_spnego_negotiate (conn=0x0, inbuf=0x4040a008 "", 
    outbuf=0x4042b008 "", length=1390, bufsize=131072, blob1=
      {data = 0x835a9b8 "`\202\004ã\006\006+\006\001\005\005\002 \202\004×0\202
\004Ó $0\"\006\t*\206H\202÷\022\001\002\002\006\t*\206H\206÷\022\001\002\002\006
\t*\206H\206÷\022\001\002\002\001", length = 1255, free = 0x8188860 
    at smbd/sesssetup.c:390
#10 0x080a00db in reply_sesssetup_and_X_spnego (conn=0x0, inbuf=0x4040a008 "", 
    outbuf=0x4042b008 "", length=1390, bufsize=131072) at smbd/sesssetup.c:505
#11 0x080a031b in reply_sesssetup_and_X (conn=0x0, inbuf=0x4040a008 "", 
    outbuf=0x4042b008 "", length=1390, bufsize=131072) at smbd/sesssetup.c:591
#12 0x080bb3b9 in switch_message (type=115, inbuf=0x4040a008 "", 
    outbuf=0x4042b008 "", size=1390, bufsize=131072) at smbd/process.c:767
#13 0x080bb45e in construct_reply (inbuf=0x4040a008 "", outbuf=0x4042b008 "", 
    size=1390, bufsize=131072) at smbd/process.c:797
#14 0x080bb767 in process_smb (inbuf=0x4040a008 "", outbuf=0x4042b008 "")
    at smbd/process.c:897
#15 0x080bc1a1 in smbd_process () at smbd/process.c:1319
#16 0x081e29e3 in main (argc=3, argv=0xbffffaf4) at smbd/server.c:887
#17 0x402510c4 in __libc_start_main () from /lib/libc.so.6
Comment 1 Tim Potter 2003-09-02 22:20:03 UTC
It looks like the kerberos library is choking on the ticket sent to us by the
server during session setup.  I'm still investigating though.
Comment 2 Tim Potter 2003-09-02 22:20:31 UTC
BTW, can't reproduce on my system.  )-:
Comment 3 Tim Potter 2003-09-02 23:37:22 UTC
Ron, some additional debugging information would be very handy.  Would you be
able to provide the following please:

  - a few pages of the smbd logfile at debug level 10 when smbd crashes

  - the contents of the local variable tkt at stack frame #7 (or maybe the
output of 'bt full' from gdb - possibly more handy)

The krb5_free_ticket() function shouldn't be crashing trying to free the ticket
as it was created using krb5_rd_req()!  The netbios name vs dns name is
interesting.  Maybe we are hitting some strange error path which is causing a
badly formed ticket to be returned.
Comment 4 Guenther Deschner 2003-09-03 07:18:12 UTC
there is a fix in current cvs (maybe already in rc2) that only tries to free a
ticket, if the ticket is =! NULL.

i'm pretty sure this will solve the problem.
Comment 5 Tim Potter 2003-09-03 15:47:51 UTC
Well that's good.  It was looking a bit tricky otherwise.

I'll mark as closed then.  Please re-open if the bug is still present.
Comment 6 Gerald (Jerry) Carter 2005-02-07 09:06:06 UTC
originally reported against one of the 3.0.0rc[1-4] releases.
Cleaning up non-production versions.
Comment 7 Gerald (Jerry) Carter 2005-08-24 10:25:29 UTC
sorry for the same, cleaning up the database to prevent unecessary reopens of bugs.
Comment 8 Gerald (Jerry) Carter 2005-11-14 09:29:12 UTC
database cleanup