2002-11-20 16:51:09

by Steven French

[permalink] [raw]
Subject: [CHECKER] 16 more potential buffer overruns in 2.5.48

Andy,

In the four fs/cifs/smbdes.c (which is based on a similar password hash in
Samba) hits from your tool the code is a little strange looking but does
not have a buffer overrun. Apparently the tool is not checking the maximum
size of the index since although the s_box array is only 256 bytes in size,
the array index is an unsigned char and can not go beyond 255 and overrun
the array. As long as unsigned char can never go above 255 the code should
work. It might have be more readable if it were defined as a __u8
instead of an unsigned char.

Thanks.

Steve French
Senior Software Engineer
Linux Technology Center - IBM Austin
phone: 512-838-2294
email: [email protected]


2002-11-20 17:05:28

by Chris Friesen

[permalink] [raw]
Subject: Re: [CHECKER] 16 more potential buffer overruns in 2.5.48

Steven French wrote:

> As long as unsigned char can never go above 255 the code should
> work. It might have be more readable if it were defined as a __u8
> instead of an unsigned char.

Technically there is nothing that guarantees that an unsigned char is <=
8 bytes in size (although in practice it often is the case).

__u8 would definately be the way to go.


--
Chris Friesen | MailStop: 043/33/F10
Nortel Networks | work: (613) 765-0557
3500 Carling Avenue | fax: (613) 765-2986
Nepean, ON K2H 8E9 Canada | email: [email protected]

2002-11-20 16:58:11

by Jeff Garzik

[permalink] [raw]
Subject: Re: [CHECKER] 16 more potential buffer overruns in 2.5.48

Steven French wrote:

> work. It might have be more readable if it were defined as a __u8



tiny pedantic point: s/__u8/u8/ if it is kernel code

2002-11-20 17:47:54

by Mark Mielke

[permalink] [raw]
Subject: Re: [CHECKER] 16 more potential buffer overruns in 2.5.48

On Wed, Nov 20, 2002 at 12:11:12PM -0500, Chris Friesen wrote:
> Steven French wrote:
> > As long as unsigned char can never go above 255 the code should
> >work. It might have be more readable if it were defined as a __u8
> >instead of an unsigned char.
> Technically there is nothing that guarantees that an unsigned char is <=
> 8 bytes in size (although in practice it often is the case).
> __u8 would definately be the way to go.

I believe C99 defines 'char' as the smallest addressable unit of
memory. Meaning -- it would be difficult to define 'u8' where 'char'
was larger than 8 bits. This is why the wchar_t stuff came about.

Is is doubtful than any new hardware would be made so difficult to
port code to. Older hardware that used 6 bit bytes (among other sizes)
should be obsoleted.

That being said... the code should probably check the size, and allow
the host compiler to choose whether or not to optimize the check away.

mark

--
[email protected]/[email protected]/[email protected] __________________________
. . _ ._ . . .__ . . ._. .__ . . . .__ | Neighbourhood Coder
|\/| |_| |_| |/ |_ |\/| | |_ | |/ |_ |
| | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada

One ring to rule them all, one ring to find them, one ring to bring them all
and in the darkness bind them...

http://mark.mielke.cc/