bug-hurd
[Top][All Lists]
Advanced

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

Re: [PATCH,HURD] hurdsock: reject negative domains


From: Pino Toscano
Subject: Re: [PATCH,HURD] hurdsock: reject negative domains
Date: Thu, 24 Nov 2011 12:46:45 +0100
User-agent: KMail/1.13.7 (Linux/3.1.0-1-amd64; KDE/4.6.5; x86_64; ; )

Alle mercoledì 23 novembre 2011, Thomas Schwinge ha scritto:
> Hi!
> 
> On Mon, 21 Nov 2011 22:23:26 +0100, Pino Toscano 
<toscano.pino@tiscali.it> wrote:
> > Reject negative socket domains right away; otherwise, it is
> > possible to read and set out-of-bounds locations of the `servers'
> > array (returning the values at those invalid memory locations),
> > and even try to deallocate ports with random values if the `dead'
> > parameter is different than zero.
> > 
> > 2011-11-21  Pino Toscano  <toscano.pino@tiscali.it>
> > 
> >     * hurd/hurdsock.c (_hurd_socket_server): Check for negative
> >     domains, and reject them.
> > 
> > --- a/hurd/hurdsock.c
> > +++ b/hurd/hurdsock.c
> > @@ -47,6 +47,12 @@ _hurd_socket_server (int domain, int dea
> > 
> >  {
> >  
> >    socket_t server;
> > 
> > +  if (domain < 0)
> > +    {
> > +      errno = EAFNOSUPPORT;
> > +      return MACH_PORT_NULL;
> > +    }
> > +
> 
> Thanks; the issue is valid, but we may want to fix it differently:
> _hurd_socket_server is an internal function, and internally we should
> always know what we're doing: that is, should only be calling it with
> valid data, such as the PF_* constants -- which is done in all places
> but socket and socketpair, which happen to be external interfaces. 
> Should instead in these two functions the domain parameter be
> checked for validity (and negative ones refused with EINVAL)?

On the other hand, the whole logic of the port cache as array (which 
make negative indexes not acceptable) is entirely in hurdsock.c, so IMHO 
it wouldn't make sense to know that (internal) logic also outide that 
file.

-- 
Pino Toscano

Attachment: signature.asc
Description: This is a digitally signed message part.


reply via email to

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