Scientific Linux Security Update : kernel on SL6.x i386/x86_64
High Nessus Plugin ID 104623
SynopsisThe remote Scientific Linux host is missing one or more security updates.
DescriptionSecurity Fix(es) :
- A race condition issue leading to a use-after-free flaw was found in the way the raw packet sockets are implemented in the Linux kernel networking subsystem handling synchronization. A local user able to open a raw packet socket (requires the CAP_NET_RAW capability) could use this flaw to elevate their privileges on the system. (CVE-2017-1000111, Important)
- An exploitable memory corruption flaw was found in the Linux kernel. The append path can be erroneously switched from UFO to non-UFO in ip_ufo_append_data() when building an UFO packet with MSG_MORE option. If unprivileged user namespaces are available, this flaw can be exploited to gain root privileges.
- A divide-by-zero vulnerability was found in the
__tcp_select_window function in the Linux kernel. This can result in a kernel panic causing a local denial of service. (CVE-2017-14106, Moderate)
Bug Fix(es) :
- When the operating system was booted with RHEV/oVirt, and the eh_deadline sysfs parameter was set to 10s, the Storage Area Network (SAN) issues caused eh_deadline to trigger with no handler. Consequently, a kernel panic occurred. This update fixes the lpfc driver, thus preventing the kernel panic under described circumstances.
- When an NFS server returned the NFS4ERR_BAD_SEQID error to an OPEN request, the open-owner was removed from the state_owners rbtree. Consequently, NFS4 client infinite loop that required a reboot to recover occurred. This update changes NFS4ERR_BAD_SEQID handling to leave the open-owner in the state_owners rbtree by updating the create_time parameter so that it looks like a new open-owner. As a result, an NFS4 client is now able to recover without falling into the infinite recovery loop after receiving NFS4ERR_BAD_SEQID.
- If an NFS client attempted to mount NFSv3 shares from an NFS server exported directly to the client's IP address, and this NFS client had already mounted other shares that originated from the same server but were exported to the subnetwork which this client was part of, the auth.unix.ip cache expiration was not handled correctly.
Consequently, the client received the 'stale file handle' errors when trying to mount the share. This update fixes handling of the cache expiration, and the NFSv3 shares now mount as expected without producing the 'stale file handle' errors.
- When running a script that raised the tx ring count to its maximum value supported by the Solarflare Network Interface Controller (NIC) driver, the EF10 family NICs allowed the settings exceeding the hardware's capability. Consequently, the Solarflare hardware became unusable with Scientific Linux 6. This update fixes the sfc driver, so that the tx ring can have maximum 2048 entries for all EF10 NICs. As a result, the Solarflare hardware no longer becomes unusable.
SolutionUpdate the affected packages.