Bug 552126 (CVE-2009-4536) - CVE-2009-4536 kernel: e1000 issue reported at 26c3
Summary: CVE-2009-4536 kernel: e1000 issue reported at 26c3
Status: CLOSED ERRATA
Alias: CVE-2009-4536
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
high
high
Target Milestone: ---
Assignee: Red Hat Product Security
QA Contact:
URL:
Whiteboard: impact=important,source=internet,publ...
Keywords: Security
Depends On: 547593 552130 552131 552132 552133 552134 552135 552136 552137 552138 553539 586019
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-01-04 06:12 UTC by Eugene Teo (Security Response)
Modified: 2018-10-27 12:51 UTC (History)
24 users (show)

(edit)
Clone Of:
(edit)
Last Closed: 2011-11-28 21:44:44 UTC


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2010:0019 normal SHIPPED_LIVE Important: kernel security update 2010-01-07 23:35:15 UTC
Red Hat Product Errata RHSA-2010:0020 normal SHIPPED_LIVE Important: kernel security update 2010-01-08 00:43:10 UTC
Red Hat Product Errata RHSA-2010:0041 normal SHIPPED_LIVE Important: kernel-rt security and bug fix update 2010-01-21 14:10:26 UTC
Red Hat Product Errata RHSA-2010:0053 normal SHIPPED_LIVE Important: kernel security and bug fix update 2010-01-20 00:07:31 UTC
Red Hat Product Errata RHSA-2010:0079 normal SHIPPED_LIVE Important: kernel security and bug fix update 2010-02-02 21:01:07 UTC
Red Hat Product Errata RHSA-2010:0095 normal SHIPPED_LIVE Important: rhev-hypervisor security and bug fix update 2010-02-09 15:23:40 UTC
Red Hat Product Errata RHSA-2010:0111 normal SHIPPED_LIVE Important: kernel security update 2010-02-16 17:04:54 UTC
Red Hat Product Errata RHSA-2010:0882 normal SHIPPED_LIVE Important: kernel security and bug fix update 2010-11-12 09:36:39 UTC

Description Eugene Teo (Security Response) 2010-01-04 06:12:10 UTC
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 06:21:21 UTC
[PATCH] e1000: enhance frame fragment detection
http://marc.info/?t=126203102000001&r=1&w=2

Comment 5 errata-xmlrpc 2010-01-07 23:35:43 UTC
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-08 00:43:51 UTC
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-20 00:07:45 UTC
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 14:10:35 UTC
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 05:58:39 UTC
Upstream patch:
http://marc.info/?l=linux-netdev&m=126394656818732&w=2

Comment 11 Chuck Ebbert 2010-01-30 13:11:41 UTC
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 21:01:21 UTC
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 17:13:20 UTC
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-05 01:48:12 UTC
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-09 04:42:42 UTC
change status to NEW.

Comment 19 errata-xmlrpc 2010-02-09 15:23:55 UTC
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 22:15:01 UTC
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 13:18:25 UTC
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 17:05:12 UTC
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 18:37:49 UTC
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 09:25:14 UTC
(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 09:36:44 UTC
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 19:28:27 UTC
seems this can be closed? no depends remain open, and this bug was fixed long ago.

Comment 33 Petr Matousek 2011-11-28 21:44:44 UTC
(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.