This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 552126 - (CVE-2009-4536) CVE-2009-4536 kernel: e1000 issue reported at 26c3
CVE-2009-4536 kernel: e1000 issue reported at 26c3
Status: CLOSED ERRATA
Product: Security Response
Classification: Other
Component: vulnerability (Show other bugs)
unspecified
All Linux
high Severity high
: ---
: ---
Assigned To: Red Hat Product Security
impact=important,source=internet,publ...
: Security
Depends On: 547593 552130 552131 552132 552133 552134 552135 552136 552137 552138 553539 586019
Blocks:
  Show dependency treegraph
 
Reported: 2010-01-04 01:12 EST by Eugene Teo (Security Response)
Modified: 2015-08-19 04:11 EDT (History)
24 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2011-11-28 16:44:44 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Eugene Teo (Security Response) 2010-01-04 01:12:10 EST
Description of problem:
This was disclosed at 26c3.

Fabian mentioned that CVE-2009-1385 has an incorrect fix. The fix he points to
is http://git.kernel.org/linus/ea30e11970a96cfe5e32c03a29332554573b4a10

Which fixes a DoS when the frame spans multiple buffers and the last buffer
contains less than four bytes. However, if that last fragment is longer than 4
bytes, it will actually be taken into account while the previous fragments will
have been ignored. This means we can end up in a situation where a single
Ethernet frame has multiple interpretation since at some level it will be
considered as a whole and in others the N first bytes will be silently
discarded.

References:
http://events.ccc.de/congress/2009/Fahrplan//events/3596.en.html
http://blog.c22.cc/2009/12/27/26c3-cat-procsysnetipv4fuckups/
http://twitter.com/dakami/statuses/7104238406
https://bugzilla.redhat.com/CVE-2009-1385
http://www.securityfocus.com/bid/37519
Comment 2 Eugene Teo (Security Response) 2010-01-04 01:21:21 EST
[PATCH] e1000: enhance frame fragment detection
http://marc.info/?t=126203102000001&r=1&w=2
Comment 5 errata-xmlrpc 2010-01-07 18:35:43 EST
This issue has been addressed in following products:

  Red Hat Enterprise Linux 5

Via RHSA-2010:0019 https://rhn.redhat.com/errata/RHSA-2010-0019.html
Comment 6 errata-xmlrpc 2010-01-07 19:43:51 EST
This issue has been addressed in following products:

  Red Hat Enterprise Linux 4

Via RHSA-2010:0020 https://rhn.redhat.com/errata/RHSA-2010-0020.html
Comment 8 errata-xmlrpc 2010-01-19 19:07:45 EST
This issue has been addressed in following products:

  Red Hat Enterprise Linux 5.3.Z - Server Only

Via RHSA-2010:0053 https://rhn.redhat.com/errata/RHSA-2010-0053.html
Comment 9 errata-xmlrpc 2010-01-21 09:10:35 EST
This issue has been addressed in following products:

  MRG for RHEL-5

Via RHSA-2010:0041 https://rhn.redhat.com/errata/RHSA-2010-0041.html
Comment 10 Eugene Teo (Security Response) 2010-01-25 00:58:39 EST
Upstream patch:
http://marc.info/?l=linux-netdev&m=126394656818732&w=2
Comment 11 Chuck Ebbert 2010-01-30 08:11:41 EST
This is now queued for 2.6.32.8 as:

  e1000-enhance-frame-fragment-detection.patch
  upstream commit 40a14deaf411592b57cb0720f0e8004293ab9865

There is also a second patch for this issue:

  e1000-e1000e-don-t-use-small-hardware-rx-buffers.patch
  upstream commit 9926146b15fd96d78a4f7c32e7a26d50639369f4
Comment 13 errata-xmlrpc 2010-02-02 16:01:21 EST
This issue has been addressed in following products:

  Red Hat Enterprise Linux 5.2 Z Stream

Via RHSA-2010:0079 https://rhn.redhat.com/errata/RHSA-2010-0079.html
Comment 14 Fedora Update System 2010-02-03 12:13:20 EST
kernel-2.6.30.10-105.2.13.fc11 has been submitted as an update for Fedora 11.
http://admin.fedoraproject.org/updates/kernel-2.6.30.10-105.2.13.fc11
Comment 15 Fedora Update System 2010-02-04 20:48:12 EST
kernel-2.6.30.10-105.2.13.fc11 has been pushed to the Fedora 11 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 18 Zhang Kexin 2010-02-08 23:42:42 EST
change status to NEW.
Comment 19 errata-xmlrpc 2010-02-09 10:23:55 EST
This issue has been addressed in following products:

  Red Hat Enterprise Virtualization for RHEL-5

Via RHSA-2010:0095 https://rhn.redhat.com/errata/RHSA-2010-0095.html
Comment 20 Fedora Update System 2010-02-09 17:15:01 EST
kernel-2.6.31.12-174.2.17.fc12 has been submitted as an update for Fedora 12.
http://admin.fedoraproject.org/updates/kernel-2.6.31.12-174.2.17.fc12
Comment 21 Fedora Update System 2010-02-16 08:18:25 EST
kernel-2.6.31.12-174.2.19.fc12 has been pushed to the Fedora 12 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 22 errata-xmlrpc 2010-02-16 12:05:12 EST
This issue has been addressed in following products:

  Red Hat Enterprise Linux 4.7 Z Stream

Via RHSA-2010:0111 https://rhn.redhat.com/errata/RHSA-2010-0111.html
Comment 28 Neil Horman 2010-03-01 13:37:49 EST
Eugene, that may be the result.  The patch as written pays no attention to set MTU size, but rather it queries the hardware status of each received frame.  If it detects a frame that was received across multiple skbs, it discards all fragments of that frame (since the driver is unable to do reassembly on it).  If the hardware recevies a frame that is exactly the size of its rx buffer, and some of that buffer is reserved for other purposes, it will span multiple buffers, and be discarded.
Comment 29 Jan Tluka 2010-03-02 04:25:14 EST
(In reply to comment #28)
> Eugene, that may be the result.  The patch as written pays no attention to set
> MTU size, but rather it queries the hardware status of each received frame.  If
> it detects a frame that was received across multiple skbs, it discards all
> fragments of that frame (since the driver is unable to do reassembly on it). 
> If the hardware recevies a frame that is exactly the size of its rx buffer, and
> some of that buffer is reserved for other purposes, it will span multiple
> buffers, and be discarded.    

Understood, I've already realized that. With mtu set to 1100 I've never seen the trimmed frames. With mtu set to 1000 I saw trimmed frames - I've sent frame with length 1100 and on the receiver got frame with length ~80.
Comment 31 errata-xmlrpc 2010-11-12 04:36:44 EST
This issue has been addressed in following products:

  Red Hat Enterprise Linux 3 Extended Lifecycle Support

Via RHSA-2010:0882 https://rhn.redhat.com/errata/RHSA-2010-0882.html
Comment 32 Jesse Brandeburg 2011-11-28 14:28:27 EST
seems this can be closed? no depends remain open, and this bug was fixed long ago.
Comment 33 Petr Matousek 2011-11-28 16:44:44 EST
(In reply to comment #32)
> seems this can be closed? no depends remain open, and this bug was fixed long
> ago.

Right, thanks for the notice. Closing.

Note You need to log in before you can comment on or make changes to this bug.