debian/changelog | 17 +++++++++++++ drivers/char/random.c | 9 ------- drivers/net/e1000/e1000.h | 2 + drivers/net/e1000/e1000_main.c | 33 +++++++++------------------ drivers/net/e1000e/e1000.h | 1 drivers/net/e1000e/netdev.c | 50 ++++++++++++++++++++--------------------- 6 files changed, 57 insertions(+), 55 deletions(-)
New commits: commit fc4dfe3a8c927f9a14d524e1f29fdea5f0643450 Author: Stephen Hemminger <[email protected]> Date: Fri Feb 5 12:25:50 2010 -0800 2.6.31-1+vyatta+30 commit b8ad600e76492201c13872ab34042f2e9ae295e7 Author: Herbert Xu <[email protected]> Date: Mon Feb 1 21:48:28 2010 +1100 random: Remove unused inode variable The previous changeset left behind an unused inode variable. This patch removes it. Reported-by: Stephen Rothwell <[email protected]> Signed-off-by: Herbert Xu <[email protected]> (cherry picked from commit cd1510cb5f892907fe1a662f90b41fb3a42954e0) commit 1908a7cf1863d096f359eca637d8105fc8698584 Author: Matt Mackall <[email protected]> Date: Fri Jan 29 21:50:36 2010 +1300 random: drop weird m_time/a_time manipulation No other driver does anything remotely like this that I know of except for the tty drivers, and I can't see any reason for random/urandom to do it. In fact, it's a (trivial, harmless) timing information leak. And obviously, it generates power- and flash-cycle wasting I/O, especially if combined with something like hwrngd. Also, it breaks ubifs's expectations. Signed-off-by: Matt Mackall <[email protected]> Signed-off-by: Herbert Xu <[email protected]> (cherry picked from commit a996996dd75a9086b12d1cb4010f26e1748993f0) commit ecd4e8443d14dcf345d7f59062e06433756e30f3 Author: Jesse Brandeburg <[email protected]> Date: Fri Jan 22 22:56:16 2010 +0000 e1000/e1000e: don't use small hardware rx buffers When testing the "e1000: enhance frame fragment detection" (and e1000e) patches we found some bugs with reducing the MTU size. The 1024 byte descriptor used with the 1000 mtu test also (re) introduced the (originally) reported bug, and causes us to need the e1000_clean_tx_irq "enhance frame fragment detection" fix. So what has occured here is that 2.6.32 is only vulnerable for mtu < 1500 due to the jumbo specific routines in both e1000 and e1000e. So, 2.6.32 needs the 2kB buffer len fix for those smaller MTUs, but is not vulnerable to the original issue reported. It has been pointed out that this vulnerability needs to be patched in older kernels that don't have the e1000 jumbo routine. Without the jumbo routines, we need the "enhance frame fragment detection" fix the e1000, old e1000e is only vulnerable for < 1500 mtu, and needs a similar fix. We split the patches up to provide easy backport paths. There is only a slight bit of extra code when this fix and the original "enhance frame fragment detection" fixes are applied, so please apply both, even though it is a bit of overkill. Signed-off-by: Jesse Brandeburg <[email protected]> Signed-off-by: Jeff Kirsher <[email protected]> Signed-off-by: David S. Miller <[email protected]> (cherry picked from commit 9926146b15fd96d78a4f7c32e7a26d50639369f4) commit e2bbff80ff35ca7453947f1913ac32bb1856acb2 Author: Jesse Brandeburg <[email protected]> Date: Tue Jan 19 14:15:59 2010 +0000 e1000e: enhance frame fragment detection Originally patched by Neil Horman <[email protected]> e1000e could with a jumbo frame enabled interface, and packet split disabled, receive a packet that would overflow a single rx buffer. While in practice very hard to craft a packet that could abuse this, it is possible. this is related to CVE-2009-4538 Signed-off-by: Jesse Brandeburg <[email protected]> CC: Neil Horman <[email protected]> Signed-off-by: Jeff Kirsher <[email protected]> Signed-off-by: David S. Miller <[email protected]> commit 03a06563b31b09d4c3a57ac12027d3d86726ccef Author: Jesse Brandeburg <[email protected]> Date: Tue Jan 19 14:15:38 2010 +0000 e1000: enhance frame fragment detection Originally From: Neil Horman <[email protected]> Modified by: Jesse Brandeburg <[email protected]> Hey all- A security discussion was recently given: http://events.ccc.de/congress/2009/Fahrplan//events/3596.en.html And a patch that I submitted awhile back was brought up. Apparently some of their testing revealed that they were able to force a buffer fragment in e1000 in which the trailing fragment was greater than 4 bytes. As a result the fragment check I introduced failed to detect the fragement and a partial invalid frame was passed up into the network stack. I've written this patch to correct it. I'm in the process of testing it now, but it makes good logical sense to me. Effectively it maintains a per-adapter state variable which detects a non-EOP frame, and discards it and subsequent non-EOP frames leading up to _and_ _including_ the next positive-EOP frame (as it is by definition the last fragment). This should prevent any and all partial frames from entering the network stack from e1000. Signed-off-by: Jesse Brandeburg <[email protected]> Acked-by: Neil Horman <[email protected]> Signed-off-by: Jeff Kirsher <[email protected]> Signed-off-by: David S. Miller <[email protected]> (cherry picked from commit 40a14deaf411592b57cb0720f0e8004293ab9865) http://suva.vyatta.com/git/?p=linux-vyatta.git;a=commitdiff;h=fc4dfe3a8c927f9a14d524e1f29fdea5f0643450 http://suva.vyatta.com/git/?p=linux-vyatta.git;a=commitdiff;h=b8ad600e76492201c13872ab34042f2e9ae295e7 http://suva.vyatta.com/git/?p=linux-vyatta.git;a=commitdiff;h=1908a7cf1863d096f359eca637d8105fc8698584 http://suva.vyatta.com/git/?p=linux-vyatta.git;a=commitdiff;h=ecd4e8443d14dcf345d7f59062e06433756e30f3 http://suva.vyatta.com/git/?p=linux-vyatta.git;a=commitdiff;h=e2bbff80ff35ca7453947f1913ac32bb1856acb2 http://suva.vyatta.com/git/?p=linux-vyatta.git;a=commitdiff;h=03a06563b31b09d4c3a57ac12027d3d86726ccef _______________________________________________ svn mailing list [email protected] http://mailman.vyatta.com/mailman/listinfo/svn
