1.74.3. RHSA-2011:1212: Important: kernel security and bug fix update

Prior to this update, a race condition in TIPC's (Transparent Inter-process Communication) recv_msg function caused kernel panic. This update modifies TIPC's socket locking logic, and kernel panic no longer occurs.

The RHSA-2009:1243 update introduced a regression in the way file locking on NFS (Network File System) was handled. This caused applications to hang if they made a lock request on a file on an NFS version 2 or 3 file system that was mounted with the sec=krb5 option. With this update, the original behavior of using mixed RPC authentication flavors for NFS and locking requests has been restored.

An incorrect call to the nfs4_drop_state_owner function caused the NFSv4 state reclaimer thread to be stuck in an infinite loop while holding the Big Kernel Lock (BKL). With this update, the aforementioned call has been removed, thus, fixing this issue.

Certain systems do not correctly set the ACPI FADT APIC mode bit. They set the bit to "cluster" mode instead of "physical" mode which caused these systems to boot without the TSC. With this update, the ACPI FADT check has been removed due to its unreliability, thus, fixing this issue.

A bug was found in the way the x86_emulate() function handled the IMUL instruction in the Xen hypervisor. On systems without support for hardware assisted paging (HAP), such as those running CPUs that do not have support for (or those that have it disabled) Intel Extended Page Tables (EPT) or AMD Virtualization (AMD-V) Rapid Virtualization Indexing (RVI), this bug could cause fully-virtualized guests to crash or lead to silent memory corruption. In reported cases, this issue occurred when booting fully-virtualized Red Hat Enterprise Linux 6.1 guests with memory cgroups enabled on a Red Hat Enterprise Linux 5.7 host.

The fix provided in CVE-2010-3432 information in sctp_packet_config(), which is called before appending data chunks to a packet, was no longer reset, ultimately causing performance issues. With this update, packet information is reset after a packet transmit, thus, fixing the aforementioned performance issues.

Prior to this update, an attempt to use the vfree() function on a vmalloc()'ed area could result in a memory leak. With this update, the underlying source code has been modified to address this issue, and a memory leak no longer occurs.

A problem with the XFS dio error handling was discovered. If a misaligned write I/O operation was issued, XFS would return -EINVAL without unlocking the inode's mutex. This caused any further operations on the inode to become unresponsive. This update adds a missing mutex_unlock operation to the dio error path, solving this issue.

Older versions of be2net cards firmware may not recognize certain commands and return illegal/unsupported errors, causing confusing error messages to appear in the logs. With this update, the driver handles these errors gracefully and does not log them.

This patch fixes the inability of the be2net driver to work in a kdump environment. It clears an interrupt bit (in the card) that may be set while the driver is probed by the kdump kernel after a crash.

When a block device object was allocated, the bd_super field was not being explicitly initialized to NULL. Previous users of the block device object may have set the bd_super field to NULL when the object is released by calling the kill_block_super() function. Some third party file systems do not always use this function and as a result the bd_super field could have become uninitialized when the object was allocated again. This could cause a kernel panic in the blkdev_releasepage() function when the uninitialised bd_super field was dereferenced. With this update, the bd_super field is properly initialized in the bdget function, and kernel panic no longer occurs.

Under some circumstances, error reports within the XFS file system could dereference a NULL pointer cause kernel panic. This update fixes the NULL pointer dereference, and kernel panic no longer occurs

This update makes the size of the three DLM hash tables consistent: 1024 entries with a Red Hat Enterprise Linux 5-specific change to allocate the tables using vmalloc allowing a higher maximum size that can be allocated for these tables. This results in improved DLM/GFS performance when there are many locks being held (that is, many GFS files being used).