netdev - RE: [patch v2] net: heap overflow in __audit

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <AE90C24D6B3A694183C094C60CF0A2F6026B7449@saturn3.aculab.com>
Date:	Wed, 27 Nov 2013 13:56:52 -0000
From:	"David Laight" <David.Laight@...LAB.COM>
To:	"Eric Wong" <normalperson@...t.net>,
	"Dan Carpenter" <dan.carpenter@...cle.com>
Cc:	"David S. Miller" <davem@...emloft.net>, <netdev@...r.kernel.org>,
	<security@...nel.org>,
	Jüri Aedla <juri.aedla@...il.com>,
	<stable@...nel.org>
Subject: RE: [patch v2] net: heap overflow in __audit_sockaddr()

> From: Eric Wong
> Dan Carpenter <dan.carpenter@...cle.com> wrote:
> > --- a/net/socket.c
> > +++ b/net/socket.c
> > @@ -1964,6 +1964,16 @@ struct used_address {
> >  	unsigned int name_len;
> >  };
> >
> > +static int copy_msghdr_from_user(struct msghdr *kmsg,
> > +				 struct msghdr __user *umsg)
> > +{
> > +	if (copy_from_user(kmsg, umsg, sizeof(struct msghdr)))
> > +		return -EFAULT;
> > +	if (kmsg->msg_namelen > sizeof(struct sockaddr_storage))
> > +		return -EINVAL;
> > +	return 0;
> 
> Crap, this seems to break Ruby trunk :x
> https://bugs.ruby-lang.org/issues/9124
> 
> I'm inclined to think Ruby is wrong to use a gigantic buffer, but this
> may also break some other existing userspace code.  I'm not sure what
> the best option since breaking userspace (even buggy userspace?) is not
> taken lightly.

Well, 'struct sockaddr_storage' is a horrid item.
I think there are people who'll say that it should never be used
to allocate an actual buffer.

If the kernel is going to write an address into the buffer, it only
needs a buffer that is long enough.
If the kernel is going to read an address, the length needs to be
appropriate for the actual protocol.

Very portable code, and code that wants to be 'future proof' against
new protocols might well use a long buffer.

	David