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
[PATCH] e1000: enhance frame fragment detection http://marc.info/?t=126203102000001&r=1&w=2
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
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
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
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
Upstream patch: http://marc.info/?l=linux-netdev&m=126394656818732&w=2
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
Patch for 2.4 kernel: http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.4.37.y.git;a=commitdiff;h=14cfd32cdfd6e14abb1b84a97f9f1740692a3df9
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
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
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.
change status to NEW.
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
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
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.
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
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.
(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.
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
seems this can be closed? no depends remain open, and this bug was fixed long ago.
(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.