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

First published: Wed Mar 11 2015(Updated: )

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

Never miss a vulnerability like this again

Sign up to SecAlerts for real-time vulnerability data matched to your software, aggregated from hundreds of sources.

Read MoreStart Free Trial

• collector/redhat-errata
• anchor-id/RHSA-2015:0674
• agent/description
• agent/event
• agent/first-publish-date
• agent/last-modified-date
• agent/references
• agent/remedy
• agent/severity
• agent/softwarecombine
• agent/tags
• agent/title
• agent/weakness
• package-manager/redhat