Bug 160117 (CVE-2005-4886) - CVE-2005-4886 Fix ipv6 exthdr bug causing Oops
Summary: CVE-2005-4886 Fix ipv6 exthdr bug causing Oops
Keywords:
Status: CLOSED ERRATA
Alias: CVE-2005-4886
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Eric Paris
QA Contact: Brian Brock
URL:
Whiteboard:
Depends On:
Blocks: 156322
TreeView+ depends on / blocked
 
Reported: 2005-06-10 19:53 UTC by Issue Tracker
Modified: 2019-09-29 12:19 UTC (History)
2 users (show)

Fixed In Version: RHSA-2005-514
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2005-10-05 13:28:11 UTC


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2005:514 qe-ready SHIPPED_LIVE Important: Updated kernel packages available for Red Hat Enterprise Linux 4 Update 2 2005-10-05 04:00:00 UTC

Description Issue Tracker 2005-06-10 19:53:57 UTC
Escalated to Bugzilla from IssueTracker

[SELINUX]: Fix ipv6_skip_exthdr() invocation causing OOPS.
author	Herbert Xu <herbert@gondor.apana.org.au>	
	Mon, 25 Apr 2005 03:16:19 +0000 (20:16 -0700)
committer	David S. Miller <davem@davemloft.net>	
	Mon, 25 Apr 2005 03:16:19 +0000 (20:16 -0700)
The SELinux hooks invoke ipv6_skip_exthdr() with an incorrect
length final argument.  However, the length argument turns out
to be superfluous.

I was just reading ipv6_skip_exthdr and it occured to me that we can
get rid of len altogether.  The only place where len is used is to
check whether the skb has two bytes for ipv6_opt_hdr.  This check
is done by skb_header_pointer/skb_copy_bits anyway.

Now it might appear that we've made the code slower by deferring
the check to skb_copy_bits.  However, this check should not trigger
in the common case so this is OK.

Comment 9 Red Hat Bugzilla 2005-10-05 13:28:11 UTC
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHSA-2005-514.html


Comment 11 Eugene Teo (Security Response) 2010-02-19 13:36:57 UTC
Upstream commit:
http://git.kernel.org/linus/0d3d077cd4f1154e63a9858e47fe3fb1ad0c03e5

Comment 12 Mark J. Cox 2010-02-19 13:53:01 UTC
This should have been given a security bug and CVE in 2005.  To figure out why it didn't here is the timeline:

Apr 22, 2005 - issue reported in netdev

Apr 24, 2005 - patch committed
               http://git.kernel.org/linus/0d3d077cd4f11
               kind of hints to security consequences
               (made upstream 2.6.12)

Apr 25, 2005 - Red Hat customer notices commit and raises internal
               issue tracker (IT) asking for a backported bug fix
               for Red Hat Enterprise Linux 4 (the only distro we
               are shipping that is affected).

Jun  9, 2005 - Bug get approval to be fixed, backported patch 
               created, committed to our source tree, this
               bug raised in bugzilla by support group.  Built 
               into an updated Red Hat kernel ready to be 
               shipped as part of RHEL4 "Update 2"

Sep 02, 2005 - Arjan mails vendor-sec mentioning that this looks to 
               have been the issue behind some recent kernel.org crashes,
               makes this a security bug, alerts Red Hat security response
               team.

Oct 05, 2005 - RHEL4 Update 2 ships containing the fix

On Sep 2nd we should have asked for a CVE name for the issue (it was before we were a naming authority) and then added it to the existing RHEL4 Update 2 security advisory.  It's too long ago to remember the reason why this didn't happen, I expect it was forgotten as no SRT action was actually required (issue was already patched and in an update release, just not actually pushed out yet).  Usually this would have been caught earlier as any of the other vendors who may have been vulnerable would have asked for a name via vendor-sec.

Brad Spengler brought this missing CVE name to our attention so we've applied for a CVE name and will update this bug and our errata with it shortly.

[this issue is CVE-2005-4886]


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