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]

Date:	Wed, 06 Jan 2010 17:15:14 -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: Thu, 7 Jan 2010 02:01:22 +0100

> entry 024 opts1 0x20803ff0 opts2 0x00000000 size 1536 <- problem starts here.
> entry 025 opts1 0x00803ff0 opts2 0x00000000 size 1536    The lines below are
> entry 026 opts1 0x00803ff0 opts2 0x00000000 size 1536    not meaningful.
> entry 027 opts1 0x00803ff0 opts2 0x00000000 size 1536
> 
> The driver will mess things up because it needs the desc->opts1.RxRes bit
> to be set before it claims that the packet is broken. Since this condition
> is not fulfilled when opts1 = 0x20803ff0, the problem goes unnoticed and
> it can be further exploited.
> 
> AFAIUI, if the driver does not lose sync (to use the paper's words), i.e.
> if it notices the condition above and stops / resets the chipset, there
> is not much to exploit.

Thanks for doing this test.

Also note the FirstFrag and LastFrag bits.  Here we see FirstFrag set,
and this indicates a fragmented frame.

The fix seems to be to simply check the error bits unconditionally, or
alternatively validate the FirstFrag and LastFrag bits
unconditionally.

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