lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <0E04AEADD178614A86F3017CC5FA693B4959924D17@MS.vivotek.tw>
Date:	Tue, 21 Apr 2009 18:09:46 +0800
From:	<jon.lin@...ics.com>
To:	<jianjun@...ux.org>, <davem@...emloft.net>
CC:	<dada1@...mosbay.com>, <netdev@...r.kernel.org>,
	<linux-kernel@...r.kernel.org>
Subject: RE: [PATCH 2.6.29.1 1/1] 8139too: fix HW initial flow

Dear Sirs,

I am so sorry for my clumsiness!
It is so embarrassed that I can't submit a valid patch...
Thank you all for your incredible patience.
I will try to use mail command in my Linux box to submit it again.
Sorry for these stupid failures.

Regards
  Jonathan


-----Original Message-----
From: Amos Kong [mailto:jianjun@...ux.org]
Sent: Tuesday, April 21, 2009 5:48 PM
To: David Miller
Cc: Jon.Lin(林宗德); dada1@...mosbay.com; netdev@...r.kernel.org; linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2.6.29.1 1/1] 8139too: fix HW initial flow

...
>> Unfortunately, this address is used by Linux kernel. So kernel panics.
>> This patch fix it by setting up DMA buffer address before RX enabled and everything is fine even under broadcast packets attack.
>>
>> Signed-off-by: Jonathan Lin <jon.lin@...ics.com>
>
>This patch does not apply, it was corrupted by your email client.
>
>I even think it has MS-DOS style newlines in it :-(

Another new patch :)


 While ifconfig eth0 up kernel calls open() of 8139 driver(8139too.c).
 In rtl8139_hw_start() of rtl8139_open(), 8139 driver enable RX before setting up the DMA
 buffer address. In this interval where RX was enabled and DMA buffer address is not yet set
 up, any incoming broadcast packet would be send to a strange physical address:
 0x003e8800 which is the default value of DMA buffer address.
 Unfortunately, this address is used by Linux kernel. So kernel panics.
 This patch fix it by setting up DMA buffer address before RX enabled and everything is fine
 even under broadcast packets attack.

Signed-off-by: Jonathan Lin <jon.lin@...ics.com>
Signed-off-by: Amos Kong <jianjun@...ux.org>

---
 drivers/net/8139too.c |   10 +++++-----
 1 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/net/8139too.c b/drivers/net/8139too.c
index 29df398..1fc4543 100644
--- a/drivers/net/8139too.c
+++ b/drivers/net/8139too.c
@@ -1383,6 +1383,11 @@ static void rtl8139_hw_start (struct net_device *dev)
        RTL_W32_F (MAC0 + 0, le32_to_cpu (*(__le32 *) (dev->dev_addr + 0)));
        RTL_W32_F (MAC0 + 4, le16_to_cpu (*(__le16 *) (dev->dev_addr + 4)));

+       tp->cur_rx = 0;
+
+       /* init Rx ring buffer DMA address */
+       RTL_W32_F (RxBuf, tp->rx_ring_dma);
+
        /* Must enable Tx/Rx before setting transfer thresholds! */
        RTL_W8 (ChipCmd, CmdRxEnb | CmdTxEnb);

@@ -1390,8 +1395,6 @@ static void rtl8139_hw_start (struct net_device *dev)
        RTL_W32 (RxConfig, tp->rx_config);
        RTL_W32 (TxConfig, rtl8139_tx_config);

-       tp->cur_rx = 0;
-
        rtl_check_media (dev, 1);

        if (tp->chipset >= CH_8139B) {
@@ -1406,9 +1409,6 @@ static void rtl8139_hw_start (struct net_device *dev)
        /* Lock Config[01234] and BMCR register writes */
        RTL_W8 (Cfg9346, Cfg9346_Lock);

-       /* init Rx ring buffer DMA address */
-       RTL_W32_F (RxBuf, tp->rx_ring_dma);
-
        /* init Tx buffer DMA addresses */
        for (i = 0; i < NUM_TX_DESC; i++)
                RTL_W32_F (TxAddr0 + (i * 4), tp->tx_bufs_dma + (tp->tx_buf[i] - tp->tx_bufs));
--
1.5.6.3


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ