CVE-2010-2943: Infoleak

Published Aug 18, 2010
·
Updated

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. xfsdb 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 openbyhandle interface can be found here:

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

Version 2: - removed useless ip->iimap.imblkno initialisation in xfsiread() - reworked a comment refering to bulkstat when it should refer to untrusted inodes. - removed typedefs from xfsimaplookup() - killed useless error logging from xfsimaplookup() - rearranged the logic flow of xfsimaplookup() 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 XFSIGETBULKSTAT to XFSIGETUNTRUSTED 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 openbyhandle() on unlinked and freed inode cluster http://oss.sgi.com/archives/xfs/2010-06/msg00191.html

Other sources

The xfs implementation in the Linux kernel before 2.6.35 does not look up inode allocation btrees before reading inode buffers, which allows remote authenticated users to read unlinked files, or read or overwrite disk blocks that are currently assigned to an active file but were previously assigned to an unlinked file, by accessing a stale NFS filehandle.

Launchpad

Affected Software

27 affected components
debian/linux-2.6
Linux Linux kernel<2.6.35
Canonical Ubuntu Linux=10.10
Canonical Ubuntu Linux=9.10
Canonical Ubuntu Linux=10.04
Canonical Ubuntu Linux=6.06
VMware ESX=4.1
VMware ESX=4.0
Avaya Aura System Manager=6.0
Avaya Aura System Manager=5.2
Avaya Aura Communication Manager=5.2
Avaya Aura System Platform=1.1
Avaya Aura System Platform=6.0
Avaya Aura System Platform=6.0-sp1
Avaya Aura System Manager=6.1
Avaya Aura System Manager=6.1.1
Avaya Aura Session Manager=1.1
Avaya Aura Session Manager=5.2
Avaya Aura Session Manager=6.0
Avaya Aura Presence Services=6.1
Avaya Aura Presence Services=6.1.1
Avaya Aura Presence Services=6.0
Avaya Iq=5.1
Avaya Iq=5.0
Avaya Aura Voice Portal=5.0
Avaya Aura Voice Portal=5.1
Avaya Aura Voice Portal=5.1-sp1

Event History

Aug 18, 2010
Data Sourced
via Red Hat·05:44 AM
DescriptionSeverityAffected Software
Sep 30, 2010
CVE Published
via MITRE·02:00 PM
Data Sourced
via MITRE·02:00 PM
Description
Jan 11, 2024
Data Sourced
via Launchpad·09:51 PM
Description
Sep 15, 2024
Data Sourced
via Ubuntu·10:39 PM
RemedyDescriptionSeverityAffected Software
Free Weekly Intel

Don't miss critical vulnerabilities

Join thousands of security professionals who receive our weekly digest of trending CVEs, zero-days, and exploited vulnerabilities.

No spam. Unsubscribe anytime.

Frequently Asked Questions

1

What is the severity of CVE-2010-2943?

CVE-2010-2943 has a high severity rating due to the potential for reading stale inode data which could compromise filesystem integrity.

2

How do I fix CVE-2010-2943?

To fix CVE-2010-2943, upgrade the Linux kernel to a version greater than 2.6.35 that contains the necessary patches.

3

Which systems are affected by CVE-2010-2943?

CVE-2010-2943 affects systems running Linux kernel versions up to 2.6.35, including various distributions like Debian and Ubuntu.

4

What is the impact of CVE-2010-2943 on data security?

The impact of CVE-2010-2943 on data security is significant as it may lead to unauthorized access to stale data, potentially exposing sensitive information.

5

Is CVE-2010-2943 fixed in newer kernel versions?

Yes, CVE-2010-2943 is fixed in newer kernel versions released after 2.6.35, which address the filehandle conversion issue.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203