summaryrefslogtreecommitdiff
path: root/drivers/net/smsc9420.c
diff options
context:
space:
mode:
authorJesse Brandeburg <jesse.brandeburg@intel.com>2010-01-19 14:15:38 +0000
committerDavid S. Miller <davem@davemloft.net>2010-01-20 16:21:22 -0800
commit40a14deaf411592b57cb0720f0e8004293ab9865 (patch)
treefc485d84b49042915e5d03a03f9bb988e8c3d175 /drivers/net/smsc9420.c
parentc1fa347f20f17f14a4a1575727fa24340e8a9117 (diff)
e1000: enhance frame fragment detection
Originally From: Neil Horman <nhorman@tuxdriver.com> Modified by: Jesse Brandeburg <jesse.brandeburg@intel.com> 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 <jesse.brandeburg@intel.com> Acked-by: Neil Horman <nhorman@tuxdriver.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Diffstat (limited to 'drivers/net/smsc9420.c')
0 files changed, 0 insertions, 0 deletions