An improper input validation vulnerability was discovered in Avaya IP Office that could allow remote command or code execution via a specially crafted web request to the Web Control component. Affected versions include all versions prior to 11.1.3.1.

An unrestricted file upload vulnerability in Avaya IP Office was discovered that could allow remote command or code execution via the One-X component. Affected versions include all versions prior to 11.1.3.1.

An OS command injection vulnerability was found in the Avaya Aura Device Services Web application which could allow remote code execution as the Web server user via a malicious uploaded file. This issue affects Avaya Aura Device Services version 8.1.4.0 and earlier.

A CSV injection vulnerability was found in the Avaya Call Management System (CMS) Supervisor web application which allows a user with administrative privileges to input crafted data which, when exported to a CSV file, may attempt arbitrary command execution on the system used to open the file by a spreadsheet software

such as Microsoft Excel.

System Manager in Avaya Aura before 7.1.2 does not properly use SSL in conjunction with authentication, which allows remote attackers to bypass intended Remote Method Invocation (RMI) restrictions, aka SMGR-26896.

The Device Mapper multipathing driver (aka multipath-tools or device-mapper-multipath) 0.4.8, as used in SUSE openSUSE, SUSE Linux Enterprise Server (SLES), Fedora, and possibly other operating systems, uses world-writable permissions for the socket file (aka /var/run/multipathd.sock), which allows local users to send arbitrary commands to the multipath daemon.

Unspecified vulnerability in SIP Enablement Services (SES) in Avaya Communication Manager 3.1.x and 4.x allows remote attackers to gain privileges and cause a denial of service via unknown vectors related to reuse of valid credentials.

Unspecified vulnerability in the SIP server in SIP Enablement Services (SES) in Avaya Communication Manager 3.1.x and 4.x allows remote authenticated users to cause a denial of service (resource consumption) via unknown vectors.

Multiple SQL injection vulnerabilities in Avaya SIP Enablement Services (SES) in Avaya Avaya Communication Manager 3.x, 4.0, and 5.0 (1) allow remote attackers to execute arbitrary SQL commands via unspecified vectors related to profiles in the SIP Personal Information Manager (SPIM) in the web interface; and allow remote authenticated users to execute arbitrary SQL commands via unspecified vectors related to (2) permissions for SPIM profiles in the web interface and (3) a crafted SIP request to the SIP server.

Unspecified vulnerability in Avaya IP Softphone 6.0 SP4 and 6.01.85 allows remote attackers to cause a denial of service (crash) via a large amount of H.323 data.

Unspecified vulnerability in the Session Initiation Protocol (SIP) implementation in Avaya one-X Desktop Edition 2.1.0.78 allows remote attackers to cause a denial of service (crash) via unspecified vectors.

SQL injection vulnerability in login.asp in Citrix Application Gateway - Broadcast Server (BCS) before 6.1, as used by Avaya AG250 - Broadcast Server before 2.0 and possibly other products, allows remote attackers to execute arbitrary SQL commands via the txtUID parameter.

Multiple unspecified vulnerabilities in the web management interface in Avaya Communication Manager (CM) 3.1 before 3.1.4 SP2, 4.0 before 4.0.3 SP1, and 5.0 before 5.0 SP3 allow remote authenticated users to execute arbitrary code via unknown attack vectors in the (1) Set Static Routes and (2) Backup History components.

Multiple unspecified vulnerabilities in the web management interface in Avaya Communication Manager (CM) 3.1.x, 4.0.3, and 5.x allow remote attackers to read (1) configuration files, (2) log files, (3) binary image files, and (4) help files via unknown vectors.

A privilege elevation vulnerability exists in the POSIX subsystem. This vulnerability could allow a logged on user to take complete control of the system.

Buffer overflow in stmkfont utility of HP-UX 10.0 through 11.22 allows local users to gain privileges via a long command line argument.

The product does not implement sufficient measures to prevent multiple failed authentication attempts within a short time frame, making it susceptible to brute-force attacks.

Avaya Fabric Connect Virtual Services Platform (VSP) Operating System Software (VOSS) before 4.2.3.0 and 5.x before 5.0.1.0 does not properly handle VLAN and I-SIS indexes, which allows remote attackers to obtain unauthorized access via crafted Ethernet frames.

An Improper access control vulnerability was found in Avaya Aura System Manager which could allow a command-line interface (CLI) user with administrative privileges to read arbitrary files on the system. Affected versions include 10.1.x.x and 10.2.x.x. Versions prior to 10.1 are end of manufacturer support.

An HTML Injection vulnerability in Avaya Spaces may have allowed disclosure of sensitive information or modification of the page content seen by the user.

An improper input validation discovered in

Avaya Call Management System could allow an unauthorized

remote command via a specially crafted web request. Affected versions include 18.x, 19.x prior to 19.2.0.7, and 20.x prior to 20.0.1.0.

A Cross-Site Scripting (XSS) vulnerability in Avaya Spaces may have allowed unauthorized code execution and potential disclose of sensitive information.

Privilege escalation related vulnerabilities were discovered in Avaya Aura Communication Manager that may allow local administrative users to escalate their privileges. This issue affects Communication Manager versions 8.0.0.0 through 8.1.3.3 and 10.1.0.0.

UNSUPPPORTED WHEN ASSIGNED Broken Access Control in User Authentication in Avaya Scopia Pathfinder 10 and 20 PTS version 8.3.7.0.4 allows remote unauthenticated attackers to bypass the login page, access sensitive information, and reset user passwords via URL modification.

A bug was found in the way headroom check was performed in udp6ufofragment() function. A remote attacker could use this flaw to crash the system.

Upstream patch: a9cf73ea7ff78f52662c8658d93c226effbbedde

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.

The dochangecipherspec function in OpenSSL 0.9.6c to 0.9.6k, and 0.9.7a to 0.9.7c, allows remote attackers to cause a denial of service (crash) via a crafted SSL/TLS handshake that triggers a null dereference.

Avaya IX Workforce Engagement v15.2.7.1195 - CWE-601: URL Redirection to Untrusted Site ('Open Redirect')

Avaya IX Workforce Engagement v15.2.7.1195 - CWE-522: Insufficiently Protected Credentials