From: Ben Hutchings <bhutchings@solarflare.com>
To: Daniel Borkmann <dborkman@redhat.com>
Cc: David Miller <davem@davemloft.net>, <netdev@vger.kernel.org>
Subject: Re: [PATCH net] packet: packet_getname_spkt: make sure string is always 0-terminated
Date: Thu, 13 Jun 2013 21:47:48 +0100 [thread overview]
Message-ID: <1371156468.2246.72.camel@bwh-desktop.uk.level5networks.com> (raw)
In-Reply-To: <51BA253B.4010701@redhat.com>
On Thu, 2013-06-13 at 22:02 +0200, Daniel Borkmann wrote:
> On 06/13/2013 07:05 PM, Ben Hutchings wrote:
> > On Thu, 2013-06-13 at 01:38 -0700, David Miller wrote:
> >> From: Daniel Borkmann <dborkman@redhat.com>
> >> Date: Wed, 12 Jun 2013 16:02:27 +0200
> >>
> >>> uaddr->sa_data is exactly of size 14, which is hard-coded here and
> >>> passed as a size argument to strncpy(). A device name can be of size
> >>> IFNAMSIZ (== 16), meaning we might leave the destination string
> >>> unterminated. Thus, use strlcpy() and also sizeof() while we're
> >>> at it. We need to memset the data area beforehand, since strlcpy
> >>> does not padd the remaining buffer with zeroes for user space, so
> >>> that we do not possibly leak anything.
> >>>
> >>> Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
> >>
> >> Applied, and queued up for -stable, thanks.
> >
> > I don't think this should be applied anywhere. Dropping support for
> > 14-character device names is a regression.
>
> I don't think this would be reasonable, because it can pose a security
> risk for user space. In all other cases, we null-terminate the string, so
> people might trust what they get from the kernel and expect this to happen
> except in this particular border case.
It seems to have been this way forever, so any userland programs already
using the API should be aware of this oddity.
> I agree that this is pretty broken, but I would say it's a bug in the kernel
> that can potentially cause user space to crash (or worse) that is making use
> of this.
It's a bug in the API but you're about 15 years too late to fix that.
> There also seems to be no man page documentation about it, only that
> spkt is heavily deprecated from what I read, and shouldn't be used nowadays.
So leave well alone!
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
next prev parent reply other threads:[~2013-06-13 20:47 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-06-12 14:02 [PATCH net] packet: packet_getname_spkt: make sure string is always 0-terminated Daniel Borkmann
2013-06-13 8:38 ` David Miller
2013-06-13 17:05 ` Ben Hutchings
2013-06-13 17:09 ` Ben Hutchings
2013-06-13 20:02 ` Daniel Borkmann
2013-06-13 20:47 ` Ben Hutchings [this message]
2013-06-13 21:17 ` Daniel Borkmann
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1371156468.2246.72.camel@bwh-desktop.uk.level5networks.com \
--to=bhutchings@solarflare.com \
--cc=davem@davemloft.net \
--cc=dborkman@redhat.com \
--cc=netdev@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.