From: Kees Cook <kees.cook@canonical.com>
To: Ben Hutchings <bhutchings@solarflare.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: Mon, 28 Feb 2011 15:51:57 -0800 [thread overview]
Message-ID: <20110228235157.GG4669@outflux.net> (raw)
In-Reply-To: <1298930141.2569.22.camel@bwh-desktop>
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. AFAIK,
reading beyond the end of &rxnfc->rule_locs[0] should be contained to
userspace memory due to the access_ok() check in copy_in_user().
> + switch (ethcmd) {
> + default:
> + break;
> + case ETHTOOL_GRXCLSRLALL:
> + /* Buffer size is variable */
> + if (get_user(rule_cnt, &compat_rxnfc->rule_cnt))
> + return -EFAULT;
> + if (rule_cnt > KMALLOC_MAX_SIZE / sizeof(u32))
> + return -ENOMEM;
> + buf_size += rule_cnt * sizeof(u32);
> + /* fall through */
> + case ETHTOOL_GRXRINGS:
> + case ETHTOOL_GRXCLSRLCNT:
> + case ETHTOOL_GRXCLSRULE:
> + convert_out = true;
> + /* fall through */
> + case ETHTOOL_SRXCLSRLDEL:
> + case ETHTOOL_SRXCLSRLINS:
> + buf_size += sizeof(struct ethtool_rxnfc);
> + convert_in = true;
> + break;
> + }
> ...
> + if (convert_out) {
> ...
> + if (ethcmd == ETHTOOL_GRXCLSRLALL) {
> + if (get_user(rule_cnt, &compat_rxnfc->rule_cnt) ||
> + copy_in_user(&compat_rxnfc->rule_locs[0],
> + &rxnfc->rule_locs[0],
> + rule_cnt * sizeof(u32)))
> + return -EFAULT;
-Kees
--
Kees Cook
Ubuntu Security Team
next prev parent reply other threads:[~2011-02-28 23:52 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 [this message]
2011-03-01 0:10 ` Ben Hutchings
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=20110228235157.GG4669@outflux.net \
--to=kees.cook@canonical.com \
--cc=alexander.h.duyck@intel.com \
--cc=bhutchings@solarflare.com \
--cc=davem@davemloft.net \
--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.