bug-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH 4/4] device/chario.c (char_write): avoid segmentation fault


From: Richard Braun
Subject: Re: [PATCH 4/4] device/chario.c (char_write): avoid segmentation fault
Date: Sun, 15 Dec 2013 15:14:55 +0100
User-agent: Mutt/1.5.21 (2010-09-15)

On Sun, Dec 15, 2013 at 02:43:50PM +0100, Marin Ramesa wrote:
> On 15.12.2013 14:00:22, Richard Braun wrote:
> > What makes you think the content could be something else than a
> > vm_map_copy object ?
> 
> Well io_data is a pointer to char, not a pointer to vm_map_copy. And 
> there is not one member in io_req structure that keeps track of the 
> io_data size. The function char_write() could be called with io_data 
> having it's origin in something other than vm_map_copy.

You're reasoning only on what you see at the language level. If you look
more closely, you'll see this case only applies when the data hasn't
been transferred in-band. I'm pretty certain the VM system will have
used a vm_map_copy object to list the pages concerned in the ou-of-band
case.

> > No, nothing guarantees that structures are null-terminated. This is a
> > very wrong assumption. In addition, even if it was possible for the
> > data to be something else than a vm_map_copy (in which case we'd want
> > an assertion, because it should *never* happen), the data size could
> > be 0, in which case simply accessing the first byte might cause a 
> > crash.
> 
> The tests I've run always show null-termination. But you're right, the 
> structure could very well contain a '\0' in which case strlen() 
> wouldn't work. But there has to be some way to detect the end of a 
> structure in memory without knowing the types.

Now you're reasoning only on what you saw with a few tests ! And no,
what you want to do here makes no sense. You can't "detect" the end of
a structure in memory. You have to know, either directly, or through
some mechanism (e.G. a header containing the real type and length).

-- 
Richard Braun



reply via email to

[Prev in Thread] Current Thread [Next in Thread]