From: Neil Horman <nhorman@tuxdriver.com>
To: Ben Hutchings <ben@decadent.org.uk>
Cc: David Miller <davem@davemloft.net>,
linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
michael.s.gilbert@gmail.com, davem@davemeloft.net,
romieu@fr.zoreil.com, eric.dumazet@gmail.com
Subject: Re: [PATCH] r8169: offical fix for CVE-2009-4537 (overlength frame DMAs)
Date: Mon, 29 Mar 2010 19:44:56 -0400 [thread overview]
Message-ID: <20100329234456.GA2070@localhost.localdomain> (raw)
In-Reply-To: <1269901265.8653.408.camel@localhost>
On Mon, Mar 29, 2010 at 11:21:05PM +0100, Ben Hutchings wrote:
> On Mon, 2010-03-29 at 15:09 -0700, David Miller wrote:
> > From: Ben Hutchings <ben@decadent.org.uk>
> > Date: Mon, 29 Mar 2010 23:01:45 +0100
> >
> > > It also sucks that the secure but low-performance behaviour is enabled
> > > for all variants, while AIUI only some suffer from the bug. I realise
> > > you probably don't have access to every variant (and neither does
> > > Francois) but perhaps you could come up with a test case that could be
> > > used to start whitelisting common variants that don't have the bug?
> >
> > As far as we know all chip variants seem to have the problem.
>
> That's not what I understood from the discussion of the early
> back-and-forth changes to receive buffer size.
>
As dave mentioned, we have no conclusive evidence that only certain chip
variants show the behavior. realtek hasn't said anything about it one way or
the other. AFAIK, all you need to do to test given chip is try to receive a
frame thats longer than configured receive filter. I only had one NIC variant
to test, and it failed that test.
> > Furthermore, this issue has been known about and investigated for
> > about 3 months. In that time no better options for handling this
> > issue reliably have been discovered and implemented.
> >
> > Feel free to code up (and test) something better yourself if you don't
> > like the fix as it exists currently. :-)
>
> I would have had a go already, if I actually had some of this hardware
> to hand. Luckily I have managed to avoid buying any so far. But if
> anyone is prepared to loan me a NIC then I promise to have a go at it.
>
I only had the one variant that failed. My hope was to make them all safe, and,
should any variants be found in the field that didn't exhibit the behavior, we
could whitelist them as they got reported.
Regards
Neil
> Ben.
>
> --
> Ben Hutchings
> Once a job is fouled up, anything done to improve it makes it worse.
next prev parent reply other threads:[~2010-03-29 23:44 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-03-29 16:03 [PATCH] r8169: offical fix for CVE-2009-4537 (overlength frame DMAs) Neil Horman
2010-03-29 20:17 ` David Miller
2010-03-29 22:01 ` Ben Hutchings
2010-03-29 22:09 ` David Miller
2010-03-29 22:21 ` Ben Hutchings
2010-03-29 23:44 ` Neil Horman [this message]
2010-04-01 0:24 ` Brandon Philips
2010-04-01 1:07 ` Neil Horman
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=20100329234456.GA2070@localhost.localdomain \
--to=nhorman@tuxdriver.com \
--cc=ben@decadent.org.uk \
--cc=davem@davemeloft.net \
--cc=davem@davemloft.net \
--cc=eric.dumazet@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=michael.s.gilbert@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=romieu@fr.zoreil.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).