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

Description of problem: The problem was in the way the gfs2 directory code was trying to re-use sentinel directory entries.

In the failing case, gfs2's rename function was renaming a file to another name that had the same non-trivial length. The file being renamed happened to be the first directory entry on the leaf block.

First, the rename code (gfs2rename in opsinode.c) found the original directory entry and decided it could do its job by simply replacing the directory entry with another. Therefore it determined correctly that no block allocations were needed.

Next, the rename code deleted the old directory entry prior to replacing it with the new name. Therefore, the soon-to-be replaced directory entry was temporarily made into a directory entry "sentinel" or a place holder at the start of a leaf block.

Lastly, it went to re-add the replacement directory entry in that leaf block. However, when gfs2direntfindspace was looking for space in the leaf block, it used the wrong value for the sentinel. That threw off its calculations so later it decides it can't really re-use the sentinel and therefore must allocate a new leaf block. But because it previously decided to re-use the directory entry, it didn't waste the time to grab a new block allocation for the inode. Therefore, the inode's ialloc pointer was still NULL and it crashes trying to reference it.

In the case of sentinel directory entries, the entire dirent is reused, not just the "free space" portion of it, and therefore the function gfs2direntfindspace should use the value 0 rather than GFS2DIRENTSIZE(0) for the actual dirent size.

Fixing this calculation enables the reproducer programs to work properly.

Description of problem: We leak at least 32bits of kernel memory to user land in tc dump, because we dont init all fields (capab ?) of the dumped structure.

Use C99 initializers so that holes and non explicit fields are zeroed.

http://patchwork.ozlabs.org/patch/61857/

A vulnerability in the local system administration component of Avaya Aura Communication Manager can allow an authenticated, privileged user on the local system to gain root privileges. Affected versions include 6.3.x and all 7.x version prior to 7.1.3.1.

Unspecified vulnerability in the Web administration interface in Avaya Communication Manager 3.1.x before CM 3.1.4 SP2 and 4.0.x before 4.0.3 SP1 allows remote authenticated administrators to gain root privileges via unknown vectors related to "configuring data viewing or restoring credentials."

The Web management interface in Avaya SIP Enablement Services (SES) 3.x and 4.0, as used with Avaya Communication Manager 3.1.x, does not perform authentication for certain functionality, which allows remote attackers to obtain sensitive information and access restricted functionality via (1) the certificate installation utility, (2) unspecified scripts in the objects folder, (3) an "unnecessary default application," (4) unspecified scripts in the states folder, (5) an unspecified "default application" that lists server configuration, and (6) "full system help."

Unspecified vulnerability in the Web management interface in Avaya SIP Enablement Services (SES) 3.x and 4.0, as used with Avaya Communication Manager 3.1.x and 4.x, allows remote authenticated administrators to gain root privileges via unknown vectors related to configuration of "data viewing or restoring parameters."

Multiple unspecified vulnerabilities in the Web management interface in Avaya SIP Enablement Services (SES) 3.x and 4.0, as used with Avaya Communication Manager 3.1.x, allow remote attackers to obtain (1) application server configuration, (2) database server configuration including encrypted passwords, (3) a system utility that decrypts "subscriber table passwords," (4) a system utility that decrypts database passwords, and (5) a system utility that encrypts "subscriber table passwords."

Unspecified vulnerability in the Web administration interface in Avaya Communication Manager 3.1.x before CM 3.1.4 SP2 and 4.0.x before 4.0.3 SP1 allows remote authenticated users to execute arbitrary commands via unknown vectors related to "viewing system logs."

Unspecified vulnerability in the Web management interface in Avaya SIP Enablement Services (SES) 3.x and 4.0, as used with Avaya Communication Manager 3.1.x, allows remote authenticated users to execute arbitrary commands via unknown vectors related to configuration of "local data viewing or restoring parameters."

The remote management interface in SIP Enablement Services (SES) Server in Avaya SIP Enablement Services 5.0, and Communication Manager (CM) 5.0 on the S8300C with SES enabled, proceeds with Core router updates even when a login is invalid, which allows remote attackers to cause a denial of service (messaging outage) or gain privileges via an update request.

The SIP Enablement Services (SES) Server in Avaya SIP Enablement Services 5.0, and Communication Manager (CM) 5.0 on the S8300C with SES enabled, writes account names and passwords to the (1) alarm and (2) system logs during failed login attempts, which allows local users to obtain login credentials by reading these logs.

The Linux kernel before 2.6.25.10 does not properly perform tty operations, which allows local users to cause a denial of service (system crash) or possibly gain privileges via vectors involving NULL pointer dereference of function pointers in (1) hamradio/6pack.c, (2) hamradio/mkiss.c, (3) irda/irtty-sir.c, (4) pppasync.c, (5) pppsynctty.c, (6) slip.c, (7) wan/x25asy.c, and (8) wireless/strip.c in drivers/net/.