Bug 624923 (CVE-2010-2943) - CVE-2010-2943 kernel: xfs: validate inode numbers in file handles correctly
Summary: CVE-2010-2943 kernel: xfs: validate inode numbers in file handles correctly
Keywords:
Status: CLOSED ERRATA
Alias: CVE-2010-2943
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Red Hat Product Security
QA Contact:
URL:
Whiteboard:
Depends On: 607031 607032 624366 633178
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-08-18 05:44 UTC by Eugene Teo (Security Response)
Modified: 2021-02-24 22:36 UTC (History)
10 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-03-28 08:51:42 UTC
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2010:0723 0 normal SHIPPED_LIVE Important: kernel security and bug fix update 2010-09-29 14:53:22 UTC

Description Eugene Teo (Security Response) 2010-08-18 05:44:36 UTC
Description of problem:
This series closes a recently discovered problem in XFS filehandle conversion.
On systems where inodes are dynamically deleted, XFS does not adequately verify
the inode numbers in the filehandles, which results in reading stale inodes
from disk and potentially returning them as valid files. Because these unlinked
inodes were never zeroed out when the chunk was deallocated, some inodes in the
chunk can still appear to have to data extents attached to them. This can lead
to stale data exposure, exposure of active data and potentially overwriting of
active data if the stale extents referenced in the unlinked inodes have been
re-allocated.

Both NFS filehandles and local filehandles provided through libhandle have this
same problem. libhandle requires root permissions to use the interface, so it
is not exposing information that you can't get more easily with other means
(e.g. xfs_db or reading directly form the block device), so there isn't really
an issue here.

For NFS, we may incorrectly accept stale file handles for unlinked inodes after
a server reboot if the unlinked inodes have not been overwritten leading to the
above issues being triggered if multiple NFS clients are accessing the same
files.

Christoph's make-bulkstat-coherent patch is the basis for this series as
bulkstat can also expose unlinked inodes and information about them back to
userspace as it makes the same assumptions about inode lookups as the file
handle interfaces.

As a result, the first two patches of the series make up the real bug fix. The
last two patches make it clear we are lookuping up untrusted inode numbers and
clear away a shortcut that these interfaces used that we do not want used any
more.  Hence for backports to other kernels, only the first two patches are
necessary.

The test program that demonstrates the issue via the open_by_handle interface
can be found here:

http://oss.sgi.com/archives/xfs/2010-06/msg00191.html

Version 2:
- removed useless ip->i_imap.im_blkno initialisation in xfs_iread()
- reworked a comment refering to bulkstat when it should refer to untrusted
  inodes.
- removed typedefs from xfs_imap_lookup()
- killed useless error logging from xfs_imap_lookup()
- rearranged the logic flow of xfs_imap_lookup() to remove the gotos.


[PATCH 0/4, V2] xfs: validate inode numbers in file handles correctly
http://article.gmane.org/gmane.comp.file-systems.xfs.general/33767

[PATCH 1/4] xfs: always use iget in bulkstat
http://article.gmane.org/gmane.comp.file-systems.xfs.general/33770

[PATCH 2/4] xfs: validate untrusted inode numbers during lookup
http://article.gmane.org/gmane.comp.file-systems.xfs.general/33771

[PATCH 3/4] xfs: rename XFS_IGET_BULKSTAT to XFS_IGET_UNTRUSTED
http://article.gmane.org/gmane.comp.file-systems.xfs.general/33768

[PATCH 4/4] xfs: remove block number from inode lookup code
http://article.gmane.org/gmane.comp.file-systems.xfs.general/33769

[PATCH] xfsqa: test open_by_handle() on unlinked and freed inode cluster
http://oss.sgi.com/archives/xfs/2010-06/msg00191.html

Comment 1 Eugene Teo (Security Response) 2010-08-18 05:45:32 UTC
A regression was found, so this patch is needed too:
http://oss.sgi.com/archives/xfs/2010-08/msg00179.html.

Comment 2 Eugene Teo (Security Response) 2010-08-23 07:27:25 UTC
Statement:

This issue did not affect the version of Linux kernel as shipped with Red Hat Enterprise Linux 3, 4, and Red Hat Enterprise MRG as they did not include support for the XFS file system. A future kernel update in Red Hat Enterprise
Linux 5 will address this issue.

Comment 3 errata-xmlrpc 2010-09-29 14:54:10 UTC
This issue has been addressed in following products:

  Red Hat Enterprise Linux 5

Via RHSA-2010:0723 https://rhn.redhat.com/errata/RHSA-2010-0723.html


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