On Wed, Jan 06, 2010 at 03:27:42PM -0800, Brandeburg, Jesse wrote: > a counter patch, without atomic ops, since we are protected by napi when > modifying this variable. > > Originally From: Neil Horman <[email protected]> > Modified by: Jesse Brandeburg <[email protected]> > > <original message> > Hey all- > A security discussion was recently given: > http://events.ccc.de/congress/2009/Fahrplan//events/3596.en.html > And a patch that I submitted awhile back was brought up. Apparently some of > their testing revealed that they were able to force a buffer fragment in e1000 > in which the trailing fragment was greater than 4 bytes. As a result the > fragment check I introduced failed to detect the fragement and a partial > invalid frame was passed up into the network stack. I've written this patch > to correct it. I'm in the process of testing it now, but it makes good > logical sense to me. Effectively it maintains a per-adapter state variable > which detects a non-EOP frame, and discards it and subsequent non-EOP frames > leading up to _and_ _including_ the next positive-EOP frame (as it is by > definition the last fragment). This should prevent any and all partial frames > from entering the network stack from e1000. > > Signed-off-by: Jesse Brandeburg <[email protected]> Seems like a fine alternative to me. Thanks! Acked-by: Neil Horman <[email protected]>
------------------------------------------------------------------------------ This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev _______________________________________________ E1000-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/e1000-devel
