netdev - Re: [PATCH RFC] r8169: straighten out overlength frame detection (v3)

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: <20100108.160252.189352309.davem@davemloft.net>
Date:	Fri, 08 Jan 2010 16:02:52 -0800 (PST)
From:	David Miller <davem@...emloft.net>
To:	romieu@...zoreil.com
Cc:	eric.dumazet@...il.com, nhorman@...driver.com,
	netdev@...r.kernel.org
Subject: Re: [PATCH RFC] r8169: straighten out overlength frame detection
 (v3)

From: Francois Romieu <romieu@...zoreil.com>
Date: Sat, 9 Jan 2010 00:48:00 +0100

> For a single packet, at the time the first interruption is received,
> 4 Rx descriptors have been written. The FirstFrag bit is set on the
> first descriptor only and the LastFrag bit is not set anywhere :
> 
> entry 019 opts1 0x20803ff0 opts2 0x00000000 used 1536 <- FirstFrag
> entry 020 opts1 0x00803ff0 opts2 0x00000000 used 1536
> entry 021 opts1 0x00803ff0 opts2 0x00000000 used 1536
> entry 022 opts1 0x00803ff0 opts2 0x00000000 used 1536
> entry 023 opts1 0x80000600 opts2 0x00000000 used 1524
>                                                  ^^^^
> (apparently we race with the DMA transfer)
>
> More events pop up, starting at 023. They are all identical to 20 / 21 /22.
> It then ends as :
> 
> entry 028 opts1 0x00803ff0 opts2 0x00000000 used 1536
> entry 029 opts1 0x10803ff0 opts2 0x00000000 used 1010 <- LastFrag bit set
> entry 030 opts1 0x80000600 opts2 0x00000000 used 000  <- 0 used byte. Entry
> entry 031 opts1 0x80000600 opts2 0x00000000 used 000     is available.
> entry 032 opts1 0x80000600 opts2 0x00000000 used 000
> 
> The total size of the DMA is not far from 16384 bytes (1536 * 10 + 1010).

My guess is that once the chip starts filling out frags like this,
the signal to trigger what should be the LastFrag entry never
propagates to the DMA engine and thus the descriptor table.

Thus the device just keeps filling packet contents with subsequent
data, with FirstFrag and LastFrag clear, until that ~16K limit is
reached.  At which point it finally sets LastFrag.

> Simply recycling the buffer may work. I'll do a few tests with it : I am
> still unable to corrupt the descriptor ring itself.

Whilst the above will end up gobbling up to (16K - BIG_PACKET_SZ)
worth of innocent frames, the DMA engine seems to keep things at least
self-consistent.

The only bug seems to be the omission of the LastFrag trigger at the
proper place.

About recycling, as far as I can tell that's exactly what the driver
already does in these exact cases, right?  If RxRes is not set, and
we don't see both FirstFrag and LastFrag set, we'll recycle the frame.

		if (unlikely(status & RxRES)) {
 ...
		} else {
 ...
			if (unlikely(rtl8169_fragmented_frame(status))) {
				dev->stats.rx_dropped++;
				dev->stats.rx_length_errors++;
				rtl8169_mark_to_asic(desc, tp->rx_buf_sz);
				continue;
			}

Therefore we shouldn't need to change anything and there is actually
no "bug" or "exploit" at all.  We just end up dropping some RX frames
because the chip didn't DMA them properly.

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