B.38.5. RHSA-2011:0421 — Important: kernel security and bug fix update
sctp_icmp_proto_unreachable()function in the Linux kernel's Stream Control Transmission Protocol (SCTP) implementation. A remote attacker could use this flaw to cause a denial of service. (CVE-2010-4526, Important)
dvb_ca_ioctl()function in the Linux kernel's
av7110module. On systems that use old DVB cards that require the
av7110module, a local, unprivileged user could use this flaw to cause a denial of service or escalate their privileges. (CVE-2011-0521, Important)
iowarrior_write()function could allow a user with access to an IO-Warrior USB device, that supports more than 8 bytes per report, to cause a denial of service or escalate their privileges. (CVE-2010-4656, Moderate)
mmap_min_addrprotection mechanism. (CVE-2010-4346, Low)
orinoco_ioctl_set_auth()function in the Linux kernel's ORiNOCO wireless extensions support implementation could render TKIP countermeasures ineffective when it is enabled, as it enabled the card instead of shutting it down. (CVE-2010-4648, Low)
ethtool_get_regs()function in the Linux kernel's ethtool IOCTL handler. A local user who has the
CAP_NET_ADMINcapability could use this flaw to cause an information leak. (CVE-2010-4655, Low)
task_show_regs()implementation. On IBM S/390 systems, a local, unprivileged user could use this flaw to read
/proc/<PID>/statusfiles, allowing them to discover the CPU register values of processes. (CVE-2011-0710, Low)
bnx2idriver 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
-EAGAINand then executing a
selectcommand for the
writecommand, caused the
selectcommand to not return any values when using the virtio serial port in a non-blocking mode. When used in blocking mode, the
writecommand 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->waitqueuepointer; however, nothing woke the
waitqueuewhen 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
writeoperations 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
virtqueueevent on the host, causing a
NULLbuffer 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
NULLto determine if a read operation would result in a block of the port. However, in some cases, a port can be
NULLeven though there are buffers left in the
virtqueueto 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_interrupthang 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/vmcorefile 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/vmcorefile is now noticeably faster.
- Reading the
/proc/vmcorefile 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/oldmemdevice in the
/proc/vmcorefile 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_watchdogkernel 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
fnic.komodules 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
fnic.komodules no longer fail to re-login.
- If a CPU is set offline, the
nohz_load_balancerCPU is updated. However, under certain circumstances, the
nohz_load_balancerCPU 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_balancerCPU 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_RESTRICToption 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/memfile (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
CONFIG_STRICT_DEVMEMconfiguration 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_enableoperation; thus, networking no longer fails under the aforementioned circumstances.