Bug 160117 (CVE-2005-4886)

Summary: CVE-2005-4886 Fix ipv6 exthdr bug causing Oops
Product: Red Hat Enterprise Linux 4 Reporter: Issue Tracker <tao>
Component: kernelAssignee: Eric Paris <eparis>
Status: CLOSED ERRATA QA Contact: Brian Brock <bbrock>
Severity: medium Docs Contact:
Priority: medium    
Version: 4.0CC: mjc, poelstra, tao
Target Milestone: ---Keywords: Security
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard: impact=important,reported=20050424,public=20050424,source=it,cvss2=7.8/AV:N/AC:L/Au:N/C:N/I:N/A:C
Fixed In Version: RHSA-2005-514 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2005-10-05 09:28:11 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Bug Depends On:    
Bug Blocks: 156322    

Description Issue Tracker 2005-06-10 15:53:57 EDT
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 09:28:11 EDT
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 08:36:57 EST
Upstream commit:
http://git.kernel.org/linus/0d3d077cd4f1154e63a9858e47fe3fb1ad0c03e5
Comment 12 Mark J. Cox (Product Security) 2010-02-19 08:53:01 EST
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]