Bug 2147 - smbd dies with signal 6 when accessed via NetBIOS
smbd dies with signal 6 when accessed via NetBIOS
Status: RESOLVED FIXED
Product: Samba 3.0
Classification: Unclassified
Component: File Services
3.0.9
All FreeBSD
: P3 critical
: none
Assigned To: Jeremy Allison
Samba QA Contact
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2004-12-10 16:22 UTC by Timur Bakeyev
Modified: 2006-01-18 08:57 UTC (History)
0 users

See Also:


Attachments
Memory dump of the packet in char *inbuf. (132.00 KB, application/octet-stream)
2004-12-10 16:23 UTC, Timur Bakeyev
no flags Details
dumb program, used to extract names from the packet (3.28 KB, text/plain)
2004-12-10 16:26 UTC, Timur Bakeyev
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Timur Bakeyev 2004-12-10 16:22:50 UTC
TO make it clear - this happens not on my box, but I got several reports as a
samba3 port maintainer for FreeBSD. So, here is the summary of the problem:

Periodicaly smbd process dies without any meaningful error log from signal 6.
Here is a typical stacktrace:

#3  0x081d8e56 in smb_panic2 (why=0x825edec "assert failed",
    decrement_pid_count=1) at lib/util.c:1464
#4  0x081d8c8f in smb_panic (why=0x825edec "assert failed") at lib/util.c:1353
#5  0x0810cff4 in name_len (s1=0x82e8026 " EGEBFGEPFCEJFEEFCNDBDBEMECEMDCCAE")
    at libsmb/nmblib.c:1340
#6  0x0809bb46 in reply_special (inbuf=0x82e8000 "\201",
    outbuf=0x8309000 "\202") at smbd/reply.c:227
#7  0x080d2712 in construct_reply (inbuf=0x82e8000 "\201",
    outbuf=0x8309000 "\202", size=76, bufsize=131072) at smbd/process.c:995
#8  0x080d2ac0 in process_smb (inbuf=0x82e8000 "\201", outbuf=0x8309000 "\202")
    at smbd/process.c:1099
#9  0x080d389c in smbd_process () at smbd/process.c:1561
#10 0x08238d46 in main (argc=2, argv=0xbfbfeb3c) at smbd/server.c:910

The typical content of the inbuf will be attached to the report. SO far I have
12 coredumps, all with the same symptoms.

Going through gdb we can see that coredump is actually happens due assertion
failure in the libsmb/nmblib.c:1340, name_len() function:

        /* Add up the length bytes. */
        for (len = 1; (*s); s += (*s) + 1) {
                len += *s + 1;
                SMB_ASSERT(len < 80);
        }

This part. After going through the packet and extracting names of the
participating peers, which look pretty legitimate, my only assumption is that
the sign in assertion is wrong, and it should look like:

SMB_ASSERT(len > 80);

Which DO have sence - NetBIOS names expected to be short, actually, not longer
than 16 chars, IIRC.

Here is the dump of the passed names:

Assert: len < 80; 34
Len: 34
|SERGSERVER     |
Assert: len < 80; 34
|FAVORITE-11LBL2|


How to fix:

Invert the condition in the assertion to:

SMB_ASSERT(len > 80);
Comment 1 Timur Bakeyev 2004-12-10 16:23:58 UTC
Created attachment 835 [details]
Memory dump of the packet in char *inbuf.

Taken via: dump binary memory
Comment 2 Timur Bakeyev 2004-12-10 16:26:50 UTC
Created attachment 836 [details]
dumb program, used to extract names from the packet

Very primitive ad-hoc program, that let to extract passed names in the packet.
Comment 3 Jeremy Allison 2004-12-10 18:03:10 UTC
I don't understand your comment here. The assertion fires if the
condition in SMB_ASSERT is False - ie. The assertion ensures that
the name length is less than 80 or equal to bytes, and forces a panic if it's
greater than 80 bytes.

Changing the sign here would panic on short names, which I don't think is
what you want.

We should probably just ignore the bad name (greater than 80 byte length)
rather than panic in smbd.

Jeremy.
Comment 4 Timur Bakeyev 2004-12-10 19:52:33 UTC
(In reply to comment #3)
> I don't understand your comment here. The assertion fires if the
> condition in SMB_ASSERT is False - ie. The assertion ensures that
> the name length is less than 80 or equal to bytes, and forces a panic if it's
> greater than 80 bytes.

I must be too sleepy now :( You absolutely right :( It was just a wilg guess,
that sparkled in my mind :(

> Changing the sign here would panic on short names, which I don't think is
> what you want.

Definitely...


> We should probably just ignore the bad name (greater than 80 byte length)
> rather than panic in smbd.

Good point...

And, what is actually happening here:

#5  0x0810cff4 in name_len (s1=0x82e8026 " EGEBFGEPFCEJFEEFCNDBDBEMECEMDCCAE") 
  at libsmb/nmblib.c:1340

If to check that passed string carefuly it seen, that it actually one charecter
longer that it supposed to be. I.e. the sting counter says - 32, but there are
33 ASCII chars before terminating '\0'.

So, in name_len() in the cycle on the first iteration 32 characters are skipped
and then *s == 'E', which makes loop to continue and len becomes equal 104,
which is obviously greater than 80...

So, this mistery is solved... But then the question arise - where that  extra
character comes from?

Apparently, it's only name_len() algorithm that is so picky about that length.
with that sanity check with name_len() skipped, name_extract() is able to
extract proper name from the passed mangled one.

This is the server NetBIOS name:

| FDEFFCEHFDEFFCFGEFFCCACACACACACA|33
|SERGSERVER     |

From the coredumps following names were extracted:

| FDFFEJEDEJEEEFFCCACACACACACACACAE|34
|SUICIDER       |
| EDFCEBFDEICACACACACACACACACACACAE|34
|CRASH          |
| EGEBFFFDFECACACACACACACACACACACAE|34
|FAUST          |
| EGEBFGEPFCEJFEEFCNDBDBEMECEMDCCAE|34
|FAVORITE-11LBL2|
| EEEFEOCACACACACACACACACACACACACAE|34
|DEN            |
| EGEMFJCACACACACACACACACACACACACAE|34
|FLY            |

So, it's not one box, that produces such broken name hashes... I suspect that
it's one of the ancient Windows versions(or, in opposit - some very new one).
I'll try to get more information from the report originator...


Comment 5 Timur Bakeyev 2004-12-11 09:17:23 UTC
At least one box was identified as Windows98. Possibly - localised(russian) version.
Comment 6 Gerald (Jerry) Carter 2005-09-29 09:41:38 UTC
Timur.  Is this still an issue in 3.0.20 ?
Comment 7 Gerald (Jerry) Carter 2006-01-18 08:57:16 UTC
closing