netdev - Re: Probably a flaw in Linux rtl8139 driver FYI

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: <49E9CF3C.2090308@cosmosbay.com>
Date:	Sat, 18 Apr 2009 15:01:48 +0200
From:	Eric Dumazet <dada1@...mosbay.com>
To:	Tzungder Lin <tzungder@...il.com>
CC:	netdev@...r.kernel.org, davem@...emloft.net
Subject: Re: Probably a flaw in Linux rtl8139 driver FYI

Tzungder Lin a écrit :
> Dear Sirs,
> 
> Hello, I am jon from Taiwan.
> First I want to thank you for your great contributions of open source.
> Thank you for your 8139 driver to make our world better.
> 
> Here is what happens:
> While I am debugging our Embedded Linux SoC I found a flaw in Linux
> 8139 driver (8139too.c) ,probably.
> If I attack (interval < 10ms) the driver with broadcast packets
> (mac.destaddr == ff:ff:ff:ff:ff:ff) when network interface up (ifconfig
> eth0 up) at the first time, the kernel space memory will be corrupted
> (overwrited with packet content) start from 0xc03e8800.
> Then kernel panics.
> 
> Here is what I discovered:
> 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.
> Therefore 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 in Linux kernel used by kmem_cache functions.
> So, kernel panics. I have tried to fix the driver by setting up DMA
> buffer address
> before RX enabled and everything is fine.
> 
> I have checked 8139too.c in both 2.4.x kernel and 2.6.x kernel, they
> both have the same initial flow.
> Here is a simple patch to show you what I found.
> 
> --- 8139too.c   2007-12-13 15:54:26.000000000 +0800
> +++ 8139too_patch.c     2009-04-17 14:56:27.000000000 +0800
> @@ -1382,6 +1382,10 @@
>        RTL_W32_F (MAC0 + 0, cpu_to_le32 (*(u32 *) (dev->dev_addr + 0)));
>        RTL_W32_F (MAC0 + 4, cpu_to_le32 (*(u32 *) (dev->dev_addr + 4)));
> 
> +       /* init Rx ring buffer DMA address */
> +       /* init before Rx enabled to avoid broadcast packet attack in
> this interval */
> +       RTL_W32_F (RxBuf, tp->rx_ring_dma);
> +
>        /* Must enable Tx/Rx before setting transfer thresholds! */
>        RTL_W8 (ChipCmd, CmdRxEnb | CmdTxEnb);
> 
> @@ -1405,8 +1409,6 @@
>        /* 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++)
> 
> Hope this can make the driver more robust.
> FYR
> Thanks a lot!
> 
> Regards
>  Jonathan Lin @Taiwan
>  2009.4.18

Hello Jonathan

This seems a nice catch !

What about also initializing tp->cur_rx = 0 *before* enabling RX too ?

So after patch we should have :

	tp->cur_rx = 0;
	RTL_W32_F (RxBuf, tp->rx_ring_dma);
        /* Must enable Tx/Rx before setting transfer thresholds! */
        RTL_W8 (ChipCmd, CmdRxEnb | CmdTxEnb);
 
Everything should be setup before enable RX interrupts coming...


--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html