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: <20100108234800.GA2908@electric-eye.fr.zoreil.com>
Date:	Sat, 9 Jan 2010 00:48:00 +0100
From:	Francois Romieu <romieu@...zoreil.com>
To:	David Miller <davem@...emloft.net>
Cc:	eric.dumazet@...il.com, nhorman@...driver.com,
	netdev@...r.kernel.org
Subject: Re: [PATCH RFC] r8169: straighten out overlength frame detection (v3)

On Wed, Jan 06, 2010 at 05:15:14PM -0800, David Miller wrote:
[...]
> I don't even think we need to reset the chip, just do what the code
> does now and recycle the buffer back to the chip as we currently do
> when RxRes is set.  We can keep a state bit around, showing that we
> saw the beginning of a fragmented frame, and we recycle buffers back
> to the chip when in state state until we see LastFrag.
> 
> That should work, right ?
> 
> In your trace, we're merely seeing the >1536 frame being chopped
> into a fragmented frame by the device.  The first one has FirstFrag
> set and the remaining (that you've shown) have neither bit set.
> 
> Did you eventually get a descriptor with LastFrag (bit 28) set?

Yes.

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

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

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