r8169: offical fix for CVE-2009-4537 (overlength frame DMAs)
in [Kernel]
|
Prev: Good Deal
Next: libata: update gfp/slab.h includes
From: David Miller on 29 Mar 2010 16:20 From: Neil Horman <nhorman(a)tuxdriver.com> Date: Mon, 29 Mar 2010 12:03:56 -0400 > Official patch to fix the r8169 frame length check error. ... > Signed-off-by: Neil Horman <nhorman(a)redhat.com> Applied, thanks a lot Neil. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: David Miller on 29 Mar 2010 18:10 From: Ben Hutchings <ben(a)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. 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. :-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Ben Hutchings on 29 Mar 2010 18:30 On Mon, 2010-03-29 at 15:09 -0700, David Miller wrote: > From: Ben Hutchings <ben(a)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. > 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. Ben. -- Ben Hutchings Once a job is fouled up, anything done to improve it makes it worse.
From: Neil Horman on 29 Mar 2010 19:50 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(a)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. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Brandon Philips on 31 Mar 2010 20:30
On 12:03 Mon 29 Mar 2010, Neil Horman wrote: > Signed-off-by: Neil Horman <nhorman(a)redhat.com> Cc: stable(a)kernel.org? Tested-by: Brandon Philips <bphilips(a)suse.de> > + if (max_frame != 16383) > + printk(KERN_WARNING "WARNING! Changing of MTU on this NIC" > + "May lead to frame reception errors!\n"); This needs a space to look right. You might as well add the PFX too: printk(KERN_WARNING PFX "WARNING! Changing of MTU on this " "NIC may lead to frame reception errors!\n"); Thanks Neil. Cheers, Brandon -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |