From: Ben Hutchings <bhutchings@solarflare.com>
To: Kees Cook <kees.cook@canonical.com>
Cc: David Miller <davem@davemloft.net>,
Alexander Duyck <alexander.h.duyck@intel.com>,
Santwona Behera <santwona.behera@sun.com>,
netdev@vger.kernel.org
Subject: Re: [PATCHv2 net-next-2.6] ethtool: Compat handling for struct ethtool_rxnfc
Date: Tue, 01 Mar 2011 00:10:33 +0000 [thread overview]
Message-ID: <1298938233.2569.30.camel@bwh-desktop> (raw)
In-Reply-To: <20110228235157.GG4669@outflux.net>
On Mon, 2011-02-28 at 15:51 -0800, Kees Cook wrote:
> Hi Ben,
>
> On Mon, Feb 28, 2011 at 09:55:41PM +0000, Ben Hutchings wrote:
> > I'm not sure whether more checks on rule_cnt are required for security
> > or whether compat_alloc_user_space() and copy_in_user() can be relied on
> > to limit any buffer overrun to the user process's own memory. It looks
> > like this is safe on x86.
>
> I'm less familiar with the compat world, but it looks sane to me. All the
> copy_in_user() calls are calculated based on structure sizes, right? Except
> for the rule_cnt one, which was already bounds-checked for output.
[...]
No, because the native ioctl implementation writes out the actual number
of rules to rxnfc->rule_cnt and we then read that back into rule_cnt
before performing the copy from rxnfc->rule_locs to
compat_rxnfc->rule_locs. So userland can race with us and modify that
value.
We could use the original value of rule_cnt to calculate the size to
copy; it would just mean copying more than we need to most of the time.
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
prev parent reply other threads:[~2011-03-01 0:10 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-02-28 21:55 [PATCHv2 net-next-2.6] ethtool: Compat handling for struct ethtool_rxnfc Ben Hutchings
2011-02-28 22:04 ` Ben Hutchings
2011-02-28 23:51 ` Kees Cook
2011-03-01 0:10 ` Ben Hutchings [this message]
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=1298938233.2569.30.camel@bwh-desktop \
--to=bhutchings@solarflare.com \
--cc=alexander.h.duyck@intel.com \
--cc=davem@davemloft.net \
--cc=kees.cook@canonical.com \
--cc=netdev@vger.kernel.org \
--cc=santwona.behera@sun.com \
/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.