Bug 460093 (CVE-2008-3526)

Summary: CVE-2008-3526 Linux kernel sctp_setsockopt_auth_key() integer overflow
Product: [Other] Security Response Reporter: Eugene Teo (Security Response) <eteo>
Component: vulnerabilityAssignee: Red Hat Product Security <security-response-team>
Status: CLOSED ERRATA QA Contact:
Severity: high Docs Contact:
Priority: high    
Version: unspecifiedCC: bhu, eric.eisenhart, lgoncalv, lwang, williams
Target Milestone: ---Keywords: Security
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2010-12-21 17:23:12 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 460094    
Bug Blocks:    
Attachments:
Description Flags
Upstream patch for this issue
none
Proposed backported patch for MRG kernel none

Description Eugene Teo (Security Response) 2008-08-26 05:57:12 UTC
Description of problem:
Eugene Teo reported that an integer overflow flaw was found in the Linux kernel sctp_setsockopt_auth_key() function. The structure used for SCTP_AUTH_KEY option contains a length that needs to be verified to prevent integer overflow conditions.

Comment 2 Eugene Teo (Security Response) 2008-08-26 06:04:23 UTC
(In reply to comment #1)
> Proposed upstream patch:
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=30c2235cbc477d4629983d440cdc4f496fec9246

There are discussions to use UINT_MAX instead of INT_MAX in the if comparison, and to limit the upper bound to a smaller number. So don't backport the patch yet.

Comment 3 Eugene Teo (Security Response) 2008-08-26 06:08:53 UTC
SCTP-AUTH API was introduced in upstream commit 65b07e5d (20070916). This extension is disabled by default since upstream commit 5e739d17 (20080821).

Comment 5 Eugene Teo (Security Response) 2008-08-26 15:07:58 UTC
(In reply to comment #2)
> (In reply to comment #1)
> > Proposed upstream patch:
> > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=30c2235cbc477d4629983d440cdc4f496fec9246
> 
> There are discussions to use UINT_MAX instead of INT_MAX in the if comparison,
> and to limit the upper bound to a smaller number. So don't backport the patch
> yet.

Vlad wrote that using INT_MAX is sufficient to catch possible overflows, and that restricting the size further is pointless and could end up being too restrictive. So, please backport the patch based on commit 30c2235cb. Thanks.

Comment 6 Eugene Teo (Security Response) 2008-08-26 15:15:47 UTC
Created attachment 315008 [details]
Upstream patch for this issue

Comment 7 Eugene Teo (Security Response) 2008-08-28 00:49:02 UTC
(In reply to comment #5)
> (In reply to comment #2)
> > (In reply to comment #1)
> > > Proposed upstream patch:
> > > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=30c2235cbc477d4629983d440cdc4f496fec9246
> > 
> > There are discussions to use UINT_MAX instead of INT_MAX in the if comparison,
> > and to limit the upper bound to a smaller number. So don't backport the patch
> > yet.
> 
> Vlad wrote that using INT_MAX is sufficient to catch possible overflows, and
> that restricting the size further is pointless and could end up being too
> restrictive. So, please backport the patch based on commit 30c2235cb. Thanks.

Turns out that the upper bound needs to be fixed :) Will update the bug with the commit hash as soon as it is committed upstream.

Comment 8 Eugene Teo (Security Response) 2008-08-29 01:36:15 UTC
The backport patch needs this as well:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=328fc47ea0bcc27d9afa69c3ad6e52431cadd76c

Comment 9 Eugene Teo (Security Response) 2008-08-29 07:42:04 UTC
Created attachment 315341 [details]
Proposed backported patch for MRG kernel

Comment 10 Luis Claudio R. Goncalves 2008-09-05 12:36:58 UTC
Queued for -79

Comment 11 Vincent Danen 2010-12-21 17:23:12 UTC
This was addressed via:

MRG Realtime for RHEL 5 Server (RHSA-2008:0857)