CVE-2009-4537

CVE-2009-4537

[Michael Gilbert]

Hi,

CVE-2009-4537 has been disclosed without any upstream activity for a
while now. Discussion about the issue dried up in January [0], and a
patch had been proposed [1], but no arguments were seen either for or
against it. Note that redhat has already shipped that in their various
kernel security updates.  Would it make sense to merge those changes
officially?

Best wishes,
Mike

[0] http://marc.info/?t=126202986900002&r=1&w=2
[1] http://marc.info/?l=linux-netdev&m=126210110408898&w=2

Re: CVE-2009-4537

[David Miller]

From: Michael Gilbert <michael.s.gilbert@gmail.com>
Date: Sat, 27 Mar 2010 14:21:00 -0400

> Hi,
> 
> CVE-2009-4537 has been disclosed without any upstream activity for a
> while now. Discussion about the issue dried up in January [0], and a
> patch had been proposed [1], but no arguments were seen either for or
> against it. Note that redhat has already shipped that in their various
> kernel security updates.  Would it make sense to merge those changes
> officially?

A different version of the fix went into the tree.

commit 8812304cf1110ae16b0778680f6022216cf4716a
Author: Raimonds Cicans <ray@apollo.lv>
Date:   Fri Nov 13 10:52:19 2009 +0000

    r8169: Fix receive buffer length when MTU is between 1515 and 1536
    
    In r8169 driver MTU is used to calculate receive buffer size.
    Receive buffer size is used to configure hardware incoming packet filter.
    
    For jumbo frames:
    Receive buffer size = Max frame size = MTU + 14 (ethernet header) + 4
    (vlan header) + 4 (ethernet checksum) = MTU + 22
    
    Bug:
    driver for all MTU up to 1536 use receive buffer size 1536
    
    As you can see from formula, this mean all IP packets > 1536 - 22
    (for vlan tagged, 1536 - 18 for not tagged) are dropped by hardware
    filter.
    
    Example:
    
    host_good>  ifconfig eth0 mtu 1536
    host_r8169> ifconfig eth0 mtu 1536
    host_good>  ping host_r8169
    Ok
    host_good>  ping -s 1500 host_r8169
    Fail
    host_good>  ifconfig eth0 mtu 7000
    host_r8169> ifconfig eth0 mtu 7000
    host_good>  ping -s 1500 host_r8169
    Ok
    
    Bonus: got rid of magic number 8
    
    Signed-off-by: Raimonds Cicans <ray@apollo.lv>
    Signed-off-by: David S. Miller <davem@davemloft.net>

diff --git a/drivers/net/r8169.c b/drivers/net/r8169.c
index fa49356..b9221bd 100644
--- a/drivers/net/r8169.c
+++ b/drivers/net/r8169.c
@@ -3243,9 +3243,9 @@ static void __devexit rtl8169_remove_one(struct pci_dev *pdev)
 static void rtl8169_set_rxbufsize(struct rtl8169_private *tp,
 				  struct net_device *dev)
 {
-	unsigned int mtu = dev->mtu;
+	unsigned int max_frame = dev->mtu + VLAN_ETH_HLEN + ETH_FCS_LEN;
 
-	tp->rx_buf_sz = (mtu > RX_BUF_SIZE) ? mtu + ETH_HLEN + 8 : RX_BUF_SIZE;
+	tp->rx_buf_sz = (max_frame > RX_BUF_SIZE) ? max_frame : RX_BUF_SIZE;
 }
 
 static int rtl8169_open(struct net_device *dev)

Re: CVE-2009-4537

[David Miller]

From: David Miller <davem@davemloft.net>
Date: Sat, 27 Mar 2010 10:34:07 -0700 (PDT)

> From: Michael Gilbert <michael.s.gilbert@gmail.com>
> Date: Sat, 27 Mar 2010 14:21:00 -0400
> 
>> Hi,
>> 
>> CVE-2009-4537 has been disclosed without any upstream activity for a
>> while now. Discussion about the issue dried up in January [0], and a
>> patch had been proposed [1], but no arguments were seen either for or
>> against it. Note that redhat has already shipped that in their various
>> kernel security updates.  Would it make sense to merge those changes
>> officially?
> 
> A different version of the fix went into the tree.

Ignore me, that was a fix for a different problem.

I was waiting for Francois to come up with a cleaner fix
but he stopped working on it, so yes I should put in
the fix you mention or something similar.

Neil, can you formally submit a version of the r8169
CVE for upstream?

Thanks.

Re: CVE-2009-4537

[Neil Horman]

On Sat, Mar 27, 2010 at 10:36:00AM -0700, David Miller wrote:
> From: David Miller <davem@davemloft.net>
> Date: Sat, 27 Mar 2010 10:34:07 -0700 (PDT)
> 
> > From: Michael Gilbert <michael.s.gilbert@gmail.com>
> > Date: Sat, 27 Mar 2010 14:21:00 -0400
> > 
> >> Hi,
> >> 
> >> CVE-2009-4537 has been disclosed without any upstream activity for a
> >> while now. Discussion about the issue dried up in January [0], and a
> >> patch had been proposed [1], but no arguments were seen either for or
> >> against it. Note that redhat has already shipped that in their various
> >> kernel security updates.  Would it make sense to merge those changes
> >> officially?
> > 
> > A different version of the fix went into the tree.
> 
> Ignore me, that was a fix for a different problem.
> 
> I was waiting for Francois to come up with a cleaner fix
> but he stopped working on it, so yes I should put in
> the fix you mention or something similar.
> 
> Neil, can you formally submit a version of the r8169
> CVE for upstream?
> 
> Thanks.
> 
Absolutley, I'll review the CVE text and my origional patch tomorrow morning,
and submit the official patch tomorrow afternoon.

Thanks!
Neil

Re: CVE-2009-4537

[Ben Hoyt]

Hi netdev,

We're working on some TCP networking stuff where the key is low
latency -- in other words, we don't really care about data throughput,
but rather getting the end-to-end TCP packet transfer time down.

I know there's quite a few networking folks and kernel hackers on this
list, so I thought I'd see if anyone was interested (or knows someone
who might be interested) in doing a few hours of consultancy work to
give us some pointers on this. I'm a competent programmer, but
kernel-level network programming is not my area of expertise.

I'm happy to receive some pointers via this list -- and others might
benefit from that too -- but I'm also keen on some dedicated
consultancy hours if anyone's interested.

Thanks,
Ben.

Re: CVE-2009-4537

[David Miller]

First, please don't hijack an unrelated thread to start talking about
something different.

Second, the mailing lists at vger.kernel.org are not for making
employment of consultancy offers.

Thanks.