Synopsis: Moderate: kernel security and bug fix update
Advisory ID: SLSA-2017:1372-1
Issue Date: 2017-05-31
CVE Numbers: CVE-2017-6214
--
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.
* 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.
* 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.
* 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.
* 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.
--
SL6
x86_64
kernel-2.6.32-696.3.1.el6.x86_64.rpm
kernel-debug-2.6.32-696.3.1.el6.x86_64.rpm
kernel-debug-debuginfo-2.6.32-696.3.1.el6.i686.rpm
kernel-debug-debuginfo-2.6.32-696.3.1.el6.x86_64.rpm
kernel-debug-devel-2.6.32-696.3.1.el6.i686.rpm
kernel-debug-devel-2.6.32-696.3.1.el6.x86_64.rpm
kernel-debuginfo-2.6.32-696.3.1.el6.i686.rpm
kernel-debuginfo-2.6.32-696.3.1.el6.x86_64.rpm
kernel-debuginfo-common-i686-2.6.32-696.3.1.el6.i686.rpm
kernel-debuginfo-common-x86_64-2.6.32-696.3.1.el6.x86_64.rpm
kernel-devel-2.6.32-696.3.1.el6.x86_64.rpm
kernel-headers-2.6.32-696.3.1.el6.x86_64.rpm
perf-2.6.32-696.3.1.el6.x86_64.rpm
perf-debuginfo-2.6.32-696.3.1.el6.i686.rpm
perf-debuginfo-2.6.32-696.3.1.el6.x86_64.rpm
python-perf-debuginfo-2.6.32-696.3.1.el6.i686.rpm
python-perf-debuginfo-2.6.32-696.3.1.el6.x86_64.rpm
python-perf-2.6.32-696.3.1.el6.x86_64.rpm
i386
kernel-2.6.32-696.3.1.el6.i686.rpm
kernel-debug-2.6.32-696.3.1.el6.i686.rpm
kernel-debug-debuginfo-2.6.32-696.3.1.el6.i686.rpm
kernel-debug-devel-2.6.32-696.3.1.el6.i686.rpm
kernel-debuginfo-2.6.32-696.3.1.el6.i686.rpm
kernel-debuginfo-common-i686-2.6.32-696.3.1.el6.i686.rpm
kernel-devel-2.6.32-696.3.1.el6.i686.rpm
kernel-headers-2.6.32-696.3.1.el6.i686.rpm
perf-2.6.32-696.3.1.el6.i686.rpm
perf-debuginfo-2.6.32-696.3.1.el6.i686.rpm
python-perf-debuginfo-2.6.32-696.3.1.el6.i686.rpm
python-perf-2.6.32-696.3.1.el6.i686.rpm
noarch
kernel-abi-whitelists-2.6.32-696.3.1.el6.noarch.rpm
kernel-doc-2.6.32-696.3.1.el6.noarch.rpm
kernel-firmware-2.6.32-696.3.1.el6.noarch.rpm
- Scientific Linux Development Team
