SecurityReason.com - Our Reason is

Security

Register | Forget Password | Login
SecurityReason
WLB
Services
RSS
Corporate
Note

If you have found a vulnerability, please send to our SecurityAlert Database :
secalert()securityreason()com

Also if you have new ( 0-day ) exploit, please send to our ExploitAlert Archive :
exploit()securityreason()com

Home arrow SecurityAlert Database

Arrow  Topic :

linux:kernel:2.6.25.15 r8169 straighten out overlength frame detection


Arrow  SecurityAlert : 6941
Arrow  CVE : CVE-2009-4537
Arrow  CWE : CWE-20
Arrow  SecurityRisk : High  Security Risk High  (About)
Arrow  Remote Exploit : Yes
Arrow  Local Exploit : No
Arrow  Victim interaction required : No
Arrow  Exploit Available : No
Arrow  Credit : Neil Horman
Arrow  Published : 14.01.2010

Arrow  Affected Software : linux:kernel:2.6.24.7
linux:kernel:2.6.25.15
intel:e1000:7.4.27
intel:e1000:7.4.35 and previous versions
intel:e1000:7.3.20
intel:e1000:7.3.15
intel:e1000:7.2.9
intel:e1000:7.2.7
intel:e1000:7.1.9
intel:e1000:7.0.41
intel:e1000:7.0.33
intel:e1000:6.3.9
intel:e1000:6.2.15
intel:e1000:6.1.16
intel:e1000:6.0.60
intel:e1000:6.0.54
intel:e1000:5.7.6
intel:e1000:5.6.10
intel:e1000:5.6.10.1
intel:e1000:5.5.4
intel:e1000:5.4.11
intel:e1000:5.3.19
intel:e1000:5.2.52
intel:e1000:5.2.30.1
intel:e1000:5.2.22



Arrow  Advisory Content :  


Hey all-
A while back Eric submitted a patch for r8169 in which the proper
allocated frame size was written to RXMaxSize to prevent the NIC from
dmaing too
much data. This was done in commit
fdd7b4c3302c93f6833e338903ea77245eb510b4. A
long time prior to that however, Francois posted
126fa4b9ca5d9d7cb7d46f779ad3bd3631ca387c, which expiclitly disabled the
MaxSize
setting due to the fact that the hardware behaved in odd ways when
overlong
frames were received on NIC's supported by this driver. This was mentioned
in a
security conference recently:
http://events.ccc.de/congress/2009/Fahrplan//events/3596.en.html

It seems that if we can't enable frame size filtering, then, as Eric
correctly
noticed, we can find ourselves DMA-ing too much data to a buffer, causing
corruption. As a result is seems that we are forced to allocate a frame
which
is ready to handle a maximally sized receive.

I've not tested the below patch at all, and clearly it stinks to have to
do.
But I thought it would be worth posting to solicit comments on it.

Thanks & Regards
Neil

Signed-off-by: Neil Horman <nhorman@tuxdriver.com>


r8169.c | 11 ++++++-----
1 file changed, 6 insertions(+), 5 deletions(-)


diff --git a/drivers/net/r8169.c b/drivers/net/r8169.c
index 60f96c4..42e3b22 100644
--- a/drivers/net/r8169.c
+++ b/drivers/net/r8169.c
@@ -63,6 +63,7 @@ static const int multicast_filter_limit = 32;
#define RX_DMA_BURST 6 /* Maximum PCI burst, '6' is 1024 */
#define TX_DMA_BURST 6 /* Maximum PCI burst, '6' is 1024 */
#define EarlyTxThld 0x3F /* 0x3F means NO early transmit */
+#define RxPacketMaxSize 0x3FE8 /* 16K - 1 - ETH_HLEN - VLAN - CRC... */
#define SafeMtu 0x1c20 /* ... actually life sucks beyond ~7k */
#define InterFrameGap 0x03 /* 3 means InterFrameGap = the shortest one */

@@ -3383,7 +3384,7 @@ static u16 rtl_rw_cpluscmd(void __iomem *ioaddr)
static void rtl_set_rx_max_size(void __iomem *ioaddr, unsigned int
rx_buf_sz)
{
/* Low hurts. Let's disable the filtering. */
- RTL_W16(RxMaxSize, rx_buf_sz + 1);
+ RTL_W16(RxMaxSize, 16383);
}

static void rtl8169_set_magic_reg(void __iomem *ioaddr, unsigned
mac_version)
@@ -3430,7 +3431,7 @@ static void rtl_hw_start_8169(struct net_device
*dev)

RTL_W8(EarlyTxThres, EarlyTxThld);

- rtl_set_rx_max_size(ioaddr, tp->rx_buf_sz);
+ rtl_set_rx_max_size(ioaddr);

if ((tp->mac_version == RTL_GIGA_MAC_VER_01) ||
(tp->mac_version == RTL_GIGA_MAC_VER_02) ||
@@ -3691,7 +3692,7 @@ static void rtl_hw_start_8168(struct net_device
*dev)

RTL_W8(EarlyTxThres, EarlyTxThld);

- rtl_set_rx_max_size(ioaddr, tp->rx_buf_sz);
+ rtl_set_rx_max_size(ioaddr);

tp->cp_cmd |= RTL_R16(CPlusCmd) | PktCntrDisable | INTT_1;

@@ -3871,7 +3872,7 @@ static void rtl_hw_start_8101(struct net_device
*dev)

RTL_W8(EarlyTxThres, EarlyTxThld);

- rtl_set_rx_max_size(ioaddr, tp->rx_buf_sz);
+ rtl_set_rx_max_size(ioaddr);

tp->cp_cmd |= rtl_rw_cpluscmd(ioaddr) | PCIMulRW;

@@ -3972,7 +3973,7 @@ static struct sk_buff *rtl8169_alloc_rx_skb(struct
pci_dev *pdev,

pad = align ? align : NET_IP_ALIGN;

- skb = netdev_alloc_skb(dev, rx_buf_sz + pad);
+ skb = netdev_alloc_skb(dev, 16383 + pad);
if (!skb)
goto err_out;

--


Arrow  References :

https://bugzilla.redhat.com/show_bug.cgi?id=550907
http://www.securityfocus.com/bid/37521
http://www.redhat.com/support/errata/RHSA-2010-0020.html
http://www.redhat.com/support/errata/RHSA-2010-0019.html
http://www.openwall.com/lists/oss-security/2009/12/31/1
http://www.openwall.com/lists/oss-security/2009/12/29/2
http://www.openwall.com/lists/oss-security/2009/12/28/1
http://twitter.com/dakami/statuses/7104238406
http://securitytracker.com/id?1023419
http://secunia.com/advisories/38031
http://marc.info/?t=126202986900002&r=1&w=2
http://marc.info/?l=linux-netdev&m=126202972828626&w=2
http://events.ccc.de/congress/2009/Fahrplan/events/3596.en.html
http://blog.c22.cc/2009/12/27/26c3-cat-procsysnetipv4fuckups/




Arrow  Feedback :

If you have additional information or notice any errors regarding this security advisory, please use contact form or email us at info()securityreason()com.
Alert

libc/fnmatch(3) DoS

Security Risk Medium- 2011-05-13

Allow attacker to denial of service apache 2.2.17 server

Apache RSS Apache Alert

» Apache HTTP Server Denial
   of Service Vulnerability

» Multiple Vendors
   libc/fnmatch(3) DoS (incl
   apache poc)

» Apache Continuum
   cross-site scripting
   vulnerability

» Apache Tomcat DoS
   Vulnerability

PHP RSS PHP Alert

» PHP Hashtables Denial of
   Service

» PHP 5.3.6 multiple null
   pointer dereference

» PHP 5.3.6 ZipArchive
   invalid use glob(3)

» libzip 0.9.3
   _zip_name_locate NULL
   Pointer Dereference (incl
   PHP 5.3.5)

ADT

Protect your family and valuables with Home Security Systems

Copyright © SecurityReason.com. All Rights Reserved.