Bug 677260 (CVE-2011-0711)

Summary:	CVE-2011-0711 kernel: xfs: prevent leaking uninitialized stack memory in FSGEOMETRY_V1
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:	low	Docs Contact:
Priority:	low
Version:	unspecified	CC:	arozansk, bhu, dchinner, dhoward, esandeen, jkacur, kernel-mgr, kmcmartin, lgoncalv, lwang, plougher, rkhan, rt-maint, rwheeler, tcallawa, vkrizan, 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:	2015-07-29 13:50:03 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:	677265, 677266, 677267, 677268, 677269
Bug Blocks:

Description Eugene Teo (Security Response) 2011-02-14 09:00:44 UTC

The FSGEOMETRY_V1 ioctl (and its compat equivalent) calls out to
xfs_fs_geometry() with a version number of 3.  This code path does not
fill in the logsunit member of the passed xfs_fsop_geom_t, leading to
the leaking of four bytes of uninitialized stack data to potentially
unprivileged callers.  Since all other members are filled in all code
paths and there are no padding bytes in this structure, it's safe to
avoid an expensive memset() in favor of just clearing this one field.

https://patchwork.kernel.org/patch/546491/

Acknowledgements:

Red Hat would like to thank Dan Rosenberg for reporting this issue.

Comment 3 Eugene Teo (Security Response) 2011-02-25 01:05:38 UTC

Upstream commit:
http://git.kernel.org/linus/3a3675b7f23f83ca8c67c9c2b6edf707fd28d1ba

Comment 4 Eric Sandeen 2011-03-01 06:55:17 UTC

There's a bug in this commit, see "[PATCH] xfs: zero proper structure size for geometry calls" on the xfs list.  But it is probably not going to affect x86_64 due to luck and padding...

Comment 5 Eugene Teo (Security Response) 2011-03-01 08:57:11 UTC

(In reply to comment #4)
> There's a bug in this commit, see "[PATCH] xfs: zero proper structure size for
> geometry calls" on the xfs list.  But it is probably not going to affect x86_64
> due to luck and padding...

Thanks for the heads-up!

http://www.spinics.net/lists/xfs/msg03801.html

Comment 6 Eugene Teo (Security Response) 2011-03-02 00:43:15 UTC

(In reply to comment #5)
> (In reply to comment #4)
> > There's a bug in this commit, see "[PATCH] xfs: zero proper structure size for
> > geometry calls" on the xfs list.  But it is probably not going to affect x86_64
> > due to luck and padding...
> 
> Thanks for the heads-up!
> 
> http://www.spinics.net/lists/xfs/msg03801.html

Version 3. http://www.spinics.net/lists/xfs/msg03806.html

Comment 7 Phillip Lougher 2011-03-04 11:45:52 UTC

(In reply to comment #6)

> 
> Version 3. http://www.spinics.net/lists/xfs/msg03806.html

Now in upstream

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=af24ee9ea8d532e16883251a6684dfa1be8eec29

Comment 8 John Kacur 2011-03-08 08:48:48 UTC

If I understand this correctly then, both commits are needed.
3a3675b7f23f83ca8c67c9c2b6edf707fd28d1ba
and
af24ee9ea8d532e16883251a6684dfa1be8eec29

Is this correct?

Comment 9 Eugene Teo (Security Response) 2011-03-08 09:19:25 UTC

(In reply to comment #8)
> If I understand this correctly then, both commits are needed.
> 3a3675b7f23f83ca8c67c9c2b6edf707fd28d1ba
> and
> af24ee9ea8d532e16883251a6684dfa1be8eec29
> 
> Is this correct?

That is correct.

Comment 10 Eric Sandeen 2011-03-10 16:27:42 UTC

Due to padding on 64-bit arches, rhel may actually be fine, since we only ship xfs with x86_64.

Nothing wrong with including the 2nd patch but if it causes lots of last-minute exception work, we may be ok without it.

Comment 11 Eugene Teo (Security Response) 2011-03-11 04:56:45 UTC

(In reply to comment #10)
> Due to padding on 64-bit arches, rhel may actually be fine, since we only ship
> xfs with x86_64.
> 
> Nothing wrong with including the 2nd patch but if it causes lots of last-minute
> exception work, we may be ok without it.

We ship XFS on the real-time kernel on both x86 and x86_64.

Comment 12 Eugene Teo (Security Response) 2011-03-11 06:15:51 UTC

Statement:

This issue did not affect the version of Linux kernel as shipped with Red Hat Enterprise Linux 4 as it did not have support for the XFS file system. This has been addressed in Red Hat Enterprise Linux 5, 6, and Red Hat Enterprise
MRG via https://rhn.redhat.com/errata/RHSA-2011-0927.html, https://rhn.redhat.com/errata/RHSA-2011-0498.html, and https://rhn.redhat.com/errata/RHSA-2011-0500.html.

Comment 13 errata-xmlrpc 2011-05-10 17:20:22 UTC

This issue has been addressed in following products:

  MRG for RHEL-5

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

Comment 14 errata-xmlrpc 2011-05-10 18:11:33 UTC

This issue has been addressed in following products:

  Red Hat Enterprise Linux 6

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

Comment 15 errata-xmlrpc 2011-07-15 06:08:52 UTC

This issue has been addressed in following products:

  Red Hat Enterprise Linux 5

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