| Description: | The kernel packages contain the Linux kernel, the core of any Linux operating system.
Security Fix(es):
A flaw was found in the Linux kernel's handling of packets with the URG flag. Applications using the splice() and tcp_splice_read() functionality can allow a remote attacker to force the kernel to enter a condition in which it can loop indefinitely. (CVE-2017-6214, Moderate)
Bug Fix(es):
When executing certain Hadoop jobs, a kernel panic occasionally occurred on multiple nodes of a cluster. This update fixes the kernel scheduler, and the kernel panic no longer occurs under the described circumstances. (BZ#1436241)
Previously, memory leak of the struct cred data structure and related data structures occasionally occurred. Consequently, system performance was suboptimal with the symptoms of high I/O operations wait and small amount of free memory. This update fixes the reference counter of the struct slab cache to no longer cause imbalance between the calls to the get_cred() function and the put_cred() function. As a result, the memory leak no longer occurs under the described circumstances. (BZ#1443234)
Previously, the be2net driver could not detect the link status properly on IBM Power Systems. Consequently, the link status was always reported as disconnected. With this update, be2net has been fixed, and the Network Interface Cards (NICs) now report the link status correctly. (BZ#1442979)
Previously, the RFF_ID and RFT_ID commands in the lpfc driver were issued in an incorrect order. Consequently, users were not able to access Logical Unit Numbers (LUNs). With this update, lpfc has been fixed to issue RFT_ID before RFF_ID, which is the correct order. As a result, users can now access LUNs as expected. (BZ#1439636)
Previously, the kdump mechanism was trying to get the lock by the vmalloc_sync_all() function during a kernel panic. Consequently, a deadlock occurred, and the crashkernel did not boot. This update fixes the vmalloc_sync_all() function to avoid synchronizing the vmalloc area on the crashing CPU. As a result, the crashkernel parameter now boots as expected, and the kernel dump is collected successfully under the described circumstances. (BZ#1443499)
|