Bug 732869 (CVE-2011-3191)

Summary:	CVE-2011-3191 kernel: cifs: signedness issue in CIFSFindNext()
Product:	[Other] Security Response	Reporter:	Eugene Teo (Security Response) <eteo>
Component:	vulnerability	Assignee:	Red Hat Product Security <security-response-team>
Status:	CLOSED ERRATA	QA Contact:
Severity:	high	Docs Contact:
Priority:	high
Version:	unspecified	CC:	anton, arozansk, bhu, davej, dhoward, fhrbata, jkacur, jlayton, kernel-mgr, kmcmartin, lgoncalv, lwang, plougher, pmatouse, rt-maint, sforsber, tcallawa, vgoyal, 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:	2012-05-10 08:23:52 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:	730354, 732471, 732870, 732873, 733154, 737482, 748683, 761363
Bug Blocks:	732735

Description Eugene Teo (Security Response) 2011-08-24 02:22:05 UTC

The name_len variable in CIFSFindNext is a signed int that gets set to the resume_name_len in the cifs_search_info. The resume_name_len however is unsigned and for some infolevels is populated directly from a 32 bit value sent by the server.

If the server sends a very large value for this, then that value could look negative when converted to a signed int. That would make that value pass the PATH_MAX check later in CIFSFindNext. The name_len would then be used as a length value for a memcpy. It would then be treated as unsigned again, and the memcpy scribbles over a ton of memory.

Fix this by making the name_len an unsigned value in CIFSFindNext.

http://www.spinics.net/lists/linux-cifs/msg03950.html

Acknowledgements:

Red Hat would like to thank Darren Lavender for reporting this issue.

Comment 3 Eugene Teo (Security Response) 2011-08-24 02:30:14 UTC

Statement:

This issue affects the Linux kernel as shipped with Red Hat Enterprise Linux 4, 5, 6, and Red Hat Enterprise MRG. It has been addressed in Red Hat Enterprise Linux 5, 6 and Red Hat Enterprise MRG via https://rhn.redhat.com/errata/RHSA-2011-1386.html, https://rhn.redhat.com/errata/RHSA-2011-1465.html, and https://rhn.redhat.com/errata/RHSA-2012-0010.html. Red Hat Enterprise Linux 4 is now in Production 3 of the maintenance life-cycle, https://access.redhat.com/support/policy/updates/errata/, therefore the fix for this issue is not currently planned to be included in the future updates.

Comment 4 Chuck Ebbert 2011-08-24 13:33:31 UTC

In linux-cifs:
http://git.kernel.org/?p=linux/kernel/git/sfrench/cifs-2.6.git;a=commitdiff;h=c32dfffaf59f73bbcf4472141b851a4dc5db2bf0

Comment 13 Eugene Teo (Security Response) 2011-10-03 03:07:07 UTC

Upstream commit: 9438fabb73eb48055b58b89fc51e0bc4db22fabd

Comment 14 errata-xmlrpc 2011-10-20 17:28:37 UTC

This issue has been addressed in following products:

  Red Hat Enterprise Linux 5

Via RHSA-2011:1386 https://rhn.redhat.com/errata/RHSA-2011-1386.html

Comment 15 Eugene Teo (Security Response) 2011-10-25 03:54:11 UTC

Created kernel tracking bugs for this issue

Affects: fedora-all [bug 748683]

Comment 16 errata-xmlrpc 2011-11-22 16:50:21 UTC

This issue has been addressed in following products:

  Red Hat Enterprise Linux 6

Via RHSA-2011:1465 https://rhn.redhat.com/errata/RHSA-2011-1465.html

Comment 18 errata-xmlrpc 2012-01-10 20:16:16 UTC

This issue has been addressed in following products:

  MRG for RHEL-6 v.2

Via RHSA-2012:0010 https://rhn.redhat.com/errata/RHSA-2012-0010.html