B.38.3. RHSA-2011:0283 — Moderate: kernel security, bug fix and enhancement update

Prior to this update, a guest could use the poll() function to find out whether the host-side connection was open or closed. However, with a SIGIO signal, this can be done asynchronously, without having to explicitly poll each port. With this update, a SIGIO signal is sent for any host connect/disconnect events. Once the SIGIO signal is received, the open/close status of virtio-serial ports can be obtained using the poll() system call.

A Red Hat Enterprise Linux 6.0 host (with root on a local disk) with dm-multipath configured on multiple LUNs (Logical Unit Number) hit kernel panic (at scsi_error_handler) with target controller faults during an I/O operation on the dm-multipath devices. This was caused by multipath using the blk_abort_queue() function to allow lower latency path deactivation. The call to blk_abort_queue proved to be unsafe due to a race (between blk_abort_queue and scsi_request_fn). With this update, the race has been resolved and kernel panic no longer occurs on Red Hat Enterprise Linux 6.0 hosts.

Prior to this update, running context-switch intensive workloads on KVM guests resulted in a large number of exits (kvm_exit) due to control register (CR) accesses by the guest, thus, resulting in poor performance. This update includes a number of optimizations which allow the guest not to exit to the hypervisor in the aforementioned case and improve the overall performance.

Handling ALUA (Asymmetric Logical Unit Access) transitioning states did not work properly due to a faulty SCSI (Small Computer System Interface) ALUA handler. With this update, optimized state transitioning prevents the aforementioned behavior.

Prior to this update, when using Red Hat Enterprise Linux 6 with a qla4xxx driver and FC (Fibre Channel) drivers using the fc class, a device might have been put in the offline state due to a transport problem. Once the transport problem was resolved, the device was not usable until a user manually corrected the state. This update enables the transition from the offline state to the running state, thus, fixing the problem.

The zfcpdump tool was not able to mount ext4 file systems. Because ext4 is the default file system on Red Hat Enterprise Linux 6, with this update, ext4 file system support was added for the zfcpdump tool.

The zfcpdump tool was not able to mount ext2 file systems. With this update, ext2 file system support was added for the zfcpdump tool.

The lock reclaim operation on a Red Hat Enterprise Linux 6 NFSv4 client did not work properly when, after a server reboot, an I/O operation which resulted in a STALE_STATEID response was performed before the RENEW call was sent to the server. This behavior was caused due to the improper use of the state flags. While investigating this bug, a different bug was discovered in the state recovery operation which resulted in a reclaim thread looping in the nfs4_reclaim_open_state() function. With this update, both operations have been fixed and work as expected.

Prior to this update, the execve utility exhibited the following flaw. When an argument and any environment data were copied from an old task's user stack to the user stack of a newly-execve'd task, the kernel would not allow the process to be interrupted or rescheduled. Therefore, when the argument or environment string data was (abnormally) large, there was no "interactivity" with the process while the execve() function was transferring the data. With this update, fatal signals (like CTRL+c) can now be received and handled and a process is allowed to yield to higher priority processes during the data transfer.

The memory cgroup controller has its own Out of Memory routine (OOM killer) and kills a process at an OOM event. However, a race condition could cause the pagefault_out_of_memory function to be called after the memory cgroup's OOM. This invoked the generic OOM killer and a panic_on_oom could occur. With this update, only the memory cgroup's OOM killer is invoked and used to kill a process should an OOM occur.

In some cases, under a small system load involve some I/O operation, processes started to lock up in the D state (that is, became unresponsive). The system load could in some cases climb steadily. This was due to the way the event channel IRQ (Interrupt Request) was set up. Xen events behave like edge-triggered IRQs, however, the kernel was setting them up as level-triggered IRQs. As a result, any action using Xen event channels could lock up a process in the D state. With this update, the handling has been changed from edge-triggered IRQs to level-triggered IRQs and process no longer lock up in the D state.

When an scsi command timed out and the fcoe/libfc driver aborted the command, a race could occur during the clean-up of the command which could result in kernel panic. With this update, the locking mechanism in the clean-up and abort paths was modified, thus, fixing the aforementioned issue.

The lack of synchronization between the clearing of the QUEUE_FLAG_CLUSTER flag and the setting of the no_cluster flag in the queue_limits variable caused corruption of data. Note that this issue only occurred on hardware that did not support segment merging (that is, clustering). With this update, the synchronization between the aforementioned flags works as expected, thus, corruption of data no longer occurs.

The virtio-console device did not handle the hot-unplug operation properly. As a result, virtio-console could access the memory outside the driver's memory area and cause kernel panic on the guest. With this update, multiple fixes to the virtio-console device resolved this issue and the hot-unplug operation works as expected.

Prior to this update, running the hwclock --systohc command could halt a running system. This was due to the interrupt transactions being looped back from a local IOH (Input/Output Hub), through the IOH to a local CPU (erroneously), which caused a conflict with I/O port operations and other transactions. With this update, the conflicts are avoided and the system continues to run after executing the hwclock --systohc command.

An I/O operation could fast fail when using Device-Mapper Multipathing (dm-multipath) if the I/O operation could be retried by the scsi layer. This prevented the multipath layer from starting its error recovery procedure and resulted in unnecessary log messages in the appropriate log files. This update includes a number of optimizations that resolve the aforementioned issue.

Outgoing packets were not fragmented after receiving the icmpv6 pkt-too-big message when using the IPSecv6 tunnel mode. This was due to the lack of IPv6 fragmentation support over an IPsec tunnel. With this update, IPv6 fragmentation is fully supported and works as expected when using the IPSecv6 tunnel mode.

Bonding, when operating in the ARP monitoring mode, made erroneous assumptions regarding the ownership of ARP frames when it received them for processing. Specifically, it was assumed that the bonding driver code was the only execution context which had access to the ARP frames network buffer data. As a result, an operation was attempted on the said buffer (specifically, to modify the size of the data buffer) which was forbidden by the kernel when a buffer was shared among several execution contexts. The result of such an operation on a shared buffer could lead to data corruption. Consequently, trying to prevent the corruption, the kernel panicked. This shared state in the network buffer could be forced to occur, for example, when running the tcpdump utility to monitor traffic on the bonding interface. Every buffer the bond interface received would be shared between the driver and the tcpdump process, thus, resulting in the aforementioned kernel panic. With this update, for the particular affected path in the bonding driver, each inbound frame is checked whether it is in the shared state. In case a buffer is shared, a private copy is made for exclusive use by the bonding driver, thus, preventing the kernel panic.

For a device that used a Target Portal Group (TPG) ID which occupied the full 2 bytes in the RTPG (Report Target Port Groups) response (with either byte exceeding the maximum value that may be stored in a signed char), the kernel's calculated TPG ID would never match the group_id that it should. As a result, this signed char overflow also caused the ALUA handler to incorrectly identify the Asymmetric Access State (AAS) of the specified device as well as incorrectly interpret the supported AAS of the target. With this update, the aforementioned issue has been addressed and no longer occurs.

The ixgbe driver has been updated to address various FCoE (Fibre Channel over Ethernet) issues related to Direct Data Placement (FCoE DDP).

The qla2xxx driver for QLogic Fibre Channel Host Bus Adapters (HBAs) has been updated to upstream version 8.03.05.01.06.1-k0, which provides a number of bug fixes and enhancements over the previous version.