RHSA-2015:0674: Important: kernel security and bug fix update

The kernel packages contain the Linux kernel, the core of any Linuxoperating system. It was found that the Linux kernel's Infiniband subsystem did not properly sanitize input parameters while registering memory regions fromuser space via the (u)verbs API. A local user with access to a/dev/infiniband/uverbsX device could use this flaw to crash the system or,potentially, escalate their privileges on the system. (CVE-2014-8159,Important) A flaw was found in the way the Linux kernel's splice() system call validated its parameters. On certain file systems, a local, unprivilegeduser could use this flaw to write past the maximum file size, and thuscrash the system. (CVE-2014-7822, Moderate) A flaw was found in the way the Linux kernel's netfilter subsystem handled generic protocol tracking. As demonstrated in the Stream ControlTransmission Protocol (SCTP) case, a remote attacker could use this flaw tobypass intended iptables rule restrictions when the associated connectiontracking module was not loaded on the system. (CVE-2014-8160, Moderate) It was found that the fix for CVE-2014-3601 was incomplete: the Linux kernel's kvmiommumappages() function still handled IOMMU mappingfailures incorrectly. A privileged user in a guest with an assigned hostdevice could use this flaw to crash the host. (CVE-2014-8369, Moderate)Red Hat would like to thank Mellanox for reporting CVE-2014-8159, and AkiraFujita of NEC for reporting CVE-2014-7822.Bug fixes: The maximum amount of entries in the IPv6 route table (net.ipv6.route.maxsize) was 4096, and every route towards this maximumsize limit was counted. Communication to more systems was impossible whenthe limit was exceeded. Now, only cached routes are counted, whichguarantees that the kernel does not run out of memory, but the user can nowinstall as many routes as the memory allows until the kernel indicates itcan no longer handle the amount of memory and returns an error message.In addition, the default "net.ipv6.route.maxsize" value has been increasedto 16384 for performance improvement reasons. (BZ#1177581) When the user attempted to scan for an FCOE-served Logical Unit Number (LUN), after an initial LUN scan, a kernel panic occurred inbnx2fcinittask. System scanning for LUNs is now stable after LUNs havebeen added. (BZ#1179098) Under certain conditions, such as when attempting to scan the network for LUNs, a race condition in the bnx2fc driver could trigger a kernel panic inbnx2fcinittask. A patch fixing a locking issue that caused the racecondition has been applied, and scanning the network for LUNs no longerleads to a kernel panic. (BZ#1179098) Previously, it was not possible to boot the kernel on Xen hypervisor in PVHVM mode if more than 32 vCPUs were specified in the guest configuration.Support for more than 32 vCPUs has been added, and the kernel now bootssuccessfully in the described situation. (BZ#1179343) When the NVMe driver allocated a namespace queue, it indicated that it was a request-based driver when it was actually a block I/O-based driver.Consequently, when NVMe driver was loaded along with a request-based dmdevice, the system could terminate unexpectedly or become unresponsive whenattempting to access data. The NVMe driver no longer sets theQUEUEFLAGSTACKABLE bit when allocating a namespace queue anddevice-mapper no longer perceives NVMe driver as request-based; systemhangs or crashes no longer occur. (BZ#1180555) If a user attempted to apply an NVRAM firmware update when running the tg3 module provided with Red Hat Enterprise Linux 6.6 kernels, the updatecould fail. As a consequence, the Network Interface Card (NIC) could stayin an unusable state and this could prevent the entire system from booting.The tg3 module has been updated to correctly apply firmware updates.(BZ#1182903) Support for key sizes of 256 and 192 bits has been added to AES-NI. (BZ#1184332)