>Number:         2996
>Category:       kern
>Synopsis:       d_name in struct direct is not as fully null padded as is indicated in dir.h
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    kern-bug-people (Kernel Bug People)
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Thu Dec  5 14:05:00 1996
>Last-Modified:
>Originator:     Greg Oster
>Organization:
>Release:        1.2_BETA
>Environment:

	System: NetBSD jimmy.usask.ca 1.2_BETA NetBSD 1.2_BETA (JIMMY) #51: Wed Dec 4 17:11:35 CST 1996 konkin@jimmy.usask.ca:/usr/src/sys/arch/hp300/compile/JIMMY hp300

 and

        System: NetBSD 1.2_BETA (JASMINE.BB) #0: Thu Aug 15 08:49:55 CST 1996
    oster@jasmine.usask.ca:/home/src/sys/arch/i386/compile/JASMINE.BB

>Description:

In /usr/include/ufs/ufs/dir.h we have the following description of the d_name
entry in struct dirent:

...
 *
 * Each DIRBLKSIZ byte block contains some number of directory entry
 * structures, which are of variable length.  Each directory entry has
 * a struct direct at the front of it, containing its inode number,
 * the length of the entry, and the length of the name contained in
 * the entry.  These are followed by the name padded to a 4 byte boundary
 * with null bytes.  All names are guaranteed null terminated.
 * The maximum length of a name in a directory is MAXNAMLEN.
 *
...

However: If we actually look at what is stored in the directory, we
see that while the direct.d_name field is indeed padded to a 4-byte
boundary, the padding with nulls is not being done.

>How-To-Repeat:

For example (I've annotated the offending bytes with "^^"'s):

oster@jasmine.usask.ca-33> cd /tmp
oster@jasmine.usask.ca-34> ls
oster@jasmine.usask.ca-35> mkdir foo
oster@jasmine.usask.ca-36> cd foo
oster@jasmine.usask.ca-37> touch a ab abc abcd abcde
oster@jasmine.usask.ca-38> ls
a       ab      abc     abcd    abcde
oster@jasmine.usask.ca-39> cd ..
oster@jasmine.usask.ca-40> od -ah foo
0000000  nul  si nul nul  ff nul eot soh   . nul nul nul stx nul nul nul
            0f00    0000    000c    0104    002e    0000    0002    0000
0000020   ff nul eot stx   .   . nul nul soh  si nul nul  ff nul  bs soh
            000c    0204    2e2e    0000    0f01    0000    000c    0108
0000040    a nul  d2  f8 stx  si nul nul  ff nul  bs stx   a   b nul  f8
            0061    f8d2    0f02    0000    000c    0208    6261    f800
                    ^^^^                                            ^^
0000060  etx  si nul nul  ff nul  bs etx   a   b   c nul eot  si nul nul
            0f03    0000    000c    0308    6261    0063    0f04    0000
0000100  dle nul  bs eot   a   b   c   d nul   <  e1  f9 enq  si nul nul
            0010    0408    6261    6463    3c00    f9e1    0f05    0000
                                            ^^      ^^^^
0000120   b4 soh  bs enq   a   b   c   d   e nul  e1  f9 nul nul nul nul
            01b4    0508    6261    6463    0065    f9e1    0000    0000
                                                    ^^^^
0000140  nul nul nul nul nul nul nul nul nul nul nul nul nul nul nul nul
            0000    0000    0000    0000    0000    0000    0000    0000
*
0001000

Am I out to lunch here (perhaps looking at the data from the wrong
angle?), or is the ufs code not quite in sync with the specification
laid out in dir.h? 

>Fix:

	I'm not sure, short of changing the description in
/usr/include/ufs/ufs/dir.h :-) (I suspect fixing this will really 
require a slight tweak to ufs_lookup() in /usr/src/sys/ufs/ufs/ufs_lookup.c) 


>Audit-Trail:
>Unformatted: