B.38.5. RHSA-2011:0421 — Important: kernel security and bug fix update

The bnx2i driver could cause a system crash on IBM POWER7 systems. The driver's page tables were not set up properly on Big Endian machines, causing extended error handling (EEH) errors on PowerPC machines. With this update, the page tables are properly set up and a system crash no longer occurs in the aforementioned case.

On platforms using an Intel 7500 or an Intel 5500 chipset (or their derivatives), occasionally, a VT-d specification defined error occurred in the kdump kernel (the second kernel). As a result of the VT-d error, on some platforms, an SMI (System Management Interrupt) was issued and the system became unresponsive. With this update, a VT-d error is properly handled so that an SMI is no longer issued, and the system no longer hangs.

Using a virtio serial port from an application, filling it until the write command returns -EAGAIN and then executing a select command for the write command, caused the select command to not return any values when using the virtio serial port in a non-blocking mode. When used in blocking mode, the write command waited until the host indicated it had used up the buffers. This was due to the fact that the poll operation waited for the port->waitqueue pointer; however, nothing woke the waitqueue when there was room again in the queue. With this update, the queue is woken via host notifications so that buffers consumed by the host can be reclaimed, the queue freed, and the application write operations may proceed again.

Prior to this update, user space could submit (using the write() operation) a buffer with zero length to be written to the host, causing the qemu hypervisor instance running on that host to crash. This was caused by the write() operation triggering a virtqueue event on the host, causing a NULL buffer to be accessed. With this update, user space is no longer allowed to submit zero-sized buffers and the aforementioned crash no longer occur.

Applications and agents using virtio serial ports would block messages even though there were messages queued up and ready to be read in the virtqueue. This was due to virtio_console's poll function checking whether a port was NULL to determine if a read operation would result in a block of the port. However, in some cases, a port can be NULL even though there are buffers left in the virtqueue to be read. This update introduces a more sophisticated method of checking whether a port contains any data; thus, preventing queued up messages from being incorrectly blocked.

If a host was slow in reading data or did not read data at all, blocking write() calls not only blocked the program that called the write() call but also the entire guest. This was caused by the write() calls waiting until an acknowledgment that the data consumed was received from the host. With this update, write() calls no longer wait for such acknowledgment: control is immediately returned to the user space application. This ensures that even if the host is busy processing other data or is not consuming data at all, the guest is not blocked.

An implementation of the SHA (Secure Hash Algorithm) hashing algorithm for the IBM System z architecture did not produce correct hashes and could potentially cause memory corruption due to broken partial block handling. A partial block could break when it was followed by an update which filled it with leftover bytes. Instead of storing the new leftover bytes at the start of the buffer, they were stored immediately after the previous partial block. With this update, the index pointer is reset, thus resolving the aforementioned partial block handling issue.

Prior to this update, performing live migration back and forth during guest installation with network adapters based on the 8168c chipset or the 8111c chipset triggered an rtl8169_interrupt hang due to a RxFIFO overflow. With this update, infinite loops in the IRQ (Interrupt Request) handler caused by RxFIFO overflows are prevented and the aforementioned hang no longer occurs.

Reading the /proc/vmcore file was previously significantly slower on a Red Hat Enterprise Linux 6 system when compared to a Red Hat Enterprise Linux 5 system. This update enables caching of memory accesses; reading of the /proc/vmcore file is now noticeably faster.

Reading the /proc/vmcore file on a Red Hat Enterprise Linux 6 system was not optimal because it did not always take advantage of reading through the cached memory. With this update, access to the /dev/oldmem device in the /proc/vmcore file is cached, resulting in faster copying to user space.

Migrating a guest could have resulted in dirty values for the guest being retained in memory, which could have caused both the guest and qemu to crash. The trigger for this was memory pages being both write-protected and dirty simultaneously. With this update, memory pages in the current bitmap are either dirty or write-protected when migrating a guest, with the result that neither qemu nor guest operating systems crash following a migration.

While not mandated by any specification, Linux systems rely on NMIs (Non-maskable Interrupts) being blocked by an IF-enabling (Interrupt Flag) STI instruction (an x86 instruction that enables interrupts; Set Interrupts); this is also the common behavior of all known hardware. Prior to this update, kernel panic could occur on guests using NMIs extensively (for example, a Linux system with the nmi_watchdog kernel parameter enabled). With this update, an NMI is disallowed when interrupts are blocked by an STI. This is done by checking for the condition and requesting an interrupt window exit if it occurs. As a result, kernel panic no longer occurs.

Under certain circumstances, a kernel thread that handles incoming messages from a server could unexpectedly exit by itself. As a result, the kernel thread would free some data structures which could then be referenced by another data structure, resulting in a kernel panic. With this update, kernel threads no longer unexpectedly exit; thus, kernel panic no longer occurs in the aforementioned case.

Operating in the FIP (FCoE Initialization Protocol) mode and performing operations that bring up ports could cause the fcoe.ko and fnic.ko modules to not be able to re-login when a port was brought back up. This was due to a bug in the FCoE (Fiber Channel over Ethernet) layer causing improper handling of FCoE LOGO frames while in the FIP mode. With this update, FCoE LOGO frames are properly handled when in the FIP mode and the fcoe.ko and fnic.ko modules no longer fail to re-login.

If a CPU is set offline, the nohz_load_balancer CPU is updated. However, under certain circumstances, the nohz_load_balancer CPU would not be updated, causing the offlined CPU to be enqueued with various timers which never expired. As a result, the system could become unresponsive. With this update, the nohz_load_balancer CPU is always updated; systems no longer become unresponsive.

The kernel syslog contains debugging information that is often useful during exploitation of other vulnerabilities such as kernel heap addresses. With this update, a new CONFIG_SECURITY_DMESG_RESTRICT option has been added to config-generic-rhel which prevents unprivileged users from reading the kernel syslog. This option is by default turned off (0), which means no restrictions.

Prior to this update, the default VF (Virtual Function) configuration was not restrictive enough. With this update, VFs only accept broadcast and multicast frames and do not accept frames from the unicast MAC address table. Restrictions are now also properly set on what can be received when the device is put in promiscuous mode. A hardware limitation was also discovered that prevented the system from properly receiving certain FCoE (Fibre Channel over Ethernet) protocol frames of a specific size. A buffer management change now allows these frames to be properly received.

PowerPC systems having more than 1 TB of RAM could randomly crash or become unresponsive due to an incorrect setup of the Segment Lookaside Buffer (SLB) entry for the kernel stack. With this update, the SLB entry is properly set up.

On IBM System z systems, user space programs could access the /dev/mem file (which contains an image of main memory), where an accidental memory (write) access could potentially be harmful. To restrict access to memory from user space through the /dev/mem file, the CONFIG_STRICT_DEVMEM configuration option has been enabled for the default kernel. The kdump and debug kernels have this option switched off by default.

Intensive usage of resources on a guest lead to a failure of networking on that guest: packets could no longer be received. The failure occurred when a DMA (Direct Memory Access) ring was consumed before NAPI (New API; an interface for networking devices which makes use of interrupt mitigation techniques) was enabled which resulted in a failure to receive the next interrupt request. The regular interrupt handler was not affected in this situation (because it can process packets in-place), however, the OOM (Out Of Memory) handler did not detect the aforementioned situation and caused networking to fail. With this update, NAPI is subsequently scheduled for each napi_enable operation; thus, networking no longer fails under the aforementioned circumstances.