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

[Ben Hutchings <ben@decadent.org.uk>]

[-- Attachment #1: Type: text/plain, Size: 1423 bytes --]

On Fri, 2010-01-08 at 16:02 -0800, David Miller wrote:
[...]
> 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.

No, the attacker controls the completion status by writing it in
previous valid frames.  Please read the slides
(<http://events.ccc.de/congress/2009/Fahrplan/attachments/1483_26c3_ipv4_fuckups.pdf> pages 80-87).

I suspect that:
1. There is an internal ring buffer for RX DMA containing both frame
payload and completion status
2. When a frame is (slightly?) over-length, the ingress and egress logic
can disagree about the length of payload in the buffer
3. This results in stale data (usually frame payload) being written to
memory as the completion status

It is conceivable that the bug can be avoided simply by rounding the 
RxMaxSize.

[...]
> 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.

The intent of the exploit is precisely to cause other packets to be
dropped!

Ben.

-- 
Ben Hutchings
Theory and practice are closer in theory than in practice.
                                - John Levine, moderator of comp.compilers

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]