Xref: utzoo unix-pc.general:2032 comp.sys.att:5191
Path: utzoo!mnetor!motto!ecijmm!ecicrl!clewis
From: clewis@ecicrl.UUCP
Newsgroups: unix-pc.general,comp.sys.att
Subject: Re: Looks like a bug in the 7300 disk driver
Message-ID: <186@ecicrl.UUCP>
Date: 12 Jan 89 04:09:19 GMT
References: <813@ttrde.UUCP> <1360@mtunb.ATT.COM> <983@mstar.UUCP> <1365@mtunb.ATT.COM>
Reply-To: clewis@ecicrl.UUCP (Chris Lewis)
Organization: Elegant Communications Inc. (CRL Division)
Lines: 32

In article <1365@mtunb.ATT.COM> jcm@mtunb.UUCP (was-John McMillan) writes:
>In article <983@mstar.UUCP> karl@mstar.UUCP (Karl Fox) writes:
>>Come on, folks!  If you provide a 4-byte buffer to read, it is a BUG to
>>write 512 bytes to it!  Sure, the raw disk device has size limitations,
>>but it should never round up.  The driver should probably return EINVAL
>>if the size isn't a multiple of 512.
>
>	OK.  I agree.  But I live in terror of making this patch and
>	finding it breaks someone's code.

Which is nothing compared to the terror of discovering that someone
has exploited this bug to overwrite his own user structure and modify
and/or crash the kernel.  (In some kernels the user area is in a protected
area at the top of a process's stack)

This is an integrity hole if not security hole.

Hint: what's in the other 508 bytes?  If the driver is so stupid
as to *round up* certain requests, how can we be sure that it's actually
checking the bounds of *any* I/O request?

This is analogous to the buffer overrun of "gets()" which someone
(who shall remain nameless) used to inject a virus into the internet.

Sheesh.

This bug should be officially reported.
-- 
Chris Lewis, Markham, Ontario, Canada
{uunet!attcan,utgpu,yunexus,utzoo}!lsuc!ecicrl!clewis
Ferret Mailing list: ...!lsuc!gate!eci386!ferret-request
(or lsuc!gate!eci386!clewis or lsuc!clewis)