linux:kernel:2.6.25.15 r8169 straighten out overlength frame detection

2010-01-13 / 2010-01-14
Credit: Neil Horman
Risk: High
Local: No
Remote: Yes
CWE: CWE-20


Ogólna skala CVSS: 7.8/10
Znaczenie: 6.9/10
Łatwość wykorzystania: 10/10
Wymagany dostęp: Zdalny
Złożoność ataku: Niska
Autoryzacja: Nie wymagana
Wpływ na poufność: Brak
Wpływ na integralność: Brak
Wpływ na dostępność: Pełny

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; --

Referencje:

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/


Vote for this issue:
50%
50%


 

Thanks for you vote!


 

Thanks for you comment!
Your message is in quarantine 48 hours.

Comment it here.


(*) - required fields.  
{{ x.nick }} | Date: {{ x.ux * 1000 | date:'yyyy-MM-dd' }} {{ x.ux * 1000 | date:'HH:mm' }} CET+1
{{ x.comment }}

Copyright 2024, cxsecurity.com

 

Back to Top