Advisory, added to svn:

type: security
subject: kernel-linus update provides 4.14 series and fixes security vulnerabilities
CVE:
 - CVE-2017-0786
 - CVE-2017-0861
 - CVE-2017-7518
 - CVE-2017-12188
 - CVE-2017-12190
 - CVE-2017-12193
 - CVE-2017-13080
 - CVE-2017-15115
 - CVE-2017-15265
 - CVE-2017-15299
 - CVE-2017-16939
 - CVE-2017-16994
 - CVE-2017-16995 
 - CVE-2017-16996
 - CVE-2017-17852
 - CVE-2017-17853
 - CVE-2017-17854
 - CVE-2017-17855
 - CVE-2017-17856
 - CVE-2017-17857
 - CVE-2017-17862
 - CVE-2017-17863
 - CVE-2017-17864
 - CVE-2017-1000407
src:
  6:
   core:
     - kernel-linus-4.14.9-1.mga6
description: |
  This kernel-linus update provides an upgrade to the 4.14 longterm
  branch, currently based on 4.14.9. It also fixes atleast the
  following security issues:

  An elevation of privilege vulnerability in the Broadcom wi-fi driver
  (CVE-2017-0786).

  Use-after-free vulnerability in the snd_pcm_info function in the ALSA
  subsystem in the Linux kernel allows attackers to gain privileges via
  unspecified vectors (CVE-2017-0861).

  Linux kernel built with the Kernel-based Virtual Machine(CONFIG_KVM)
  support is vulnerable to an incorrect debug exception(#DB) error. It
  could occur while emulating a syscall instruction. A user/process
  inside guest could use this flaw to potentially escalate their
  privileges inside guest. Linux guests are not affected.(CVE-2017-7518).

  arch/x86/kvm/mmu.c in the Linux kernel through 4.13.5, when nested
  virtualisation is used, does not properly traverse guest pagetable
  entries to resolve a guest virtual address, which allows L1 guest OS
  users to execute arbitrary code on the host OS or cause a denial of
  service (incorrect index during page walking, and host OS crash), aka
  an "MMU potential stack buffer overrun" (CVE-2017-12188).

  The bio_map_user_iov and bio_unmap_user functions in block/bio.c in the
  Linux kernel before 4.13.8 do unbalanced refcounting when a SCSI I/O
  vector has small consecutive buffers belonging to the same page. The
  bio_add_pc_page function merges them into one, but the page reference
  is never dropped. This causes a memory leak and possible system lockup
  (exploitable against the host OS by a guest OS user, if a SCSI disk is
  passed through to a virtual machine) due to an out-of-memory condition
  (CVE-2017-12190).

  The assoc_array_insert_into_terminal_node function in lib/assoc_array.c
  in the Linux kernel before 4.13.11 mishandles node splitting, which allows
  local users to cause a denial of service (NULL pointer dereference and
  panic) via a crafted application, as demonstrated by the keyring key type,
  and key addition and link creation operations (CVE-2017-12193).

  Wi-Fi Protected Access (WPA and WPA2) allows reinstallation of the Group
  Temporal Key (GTK) during the group key handshake, allowing an attacker
  within radio range to replay frames from access points to clients
  (CVE-2017-13080).

  The sctp_do_peeloff function in net/sctp/socket.c in the Linux kernel
  before 4.14 does not check whether the intended netns is used in a
  peel-off action, which allows local users to cause a denial of
  service (use-after-free and system crash) or possibly have unspecified
  other impact via crafted system calls (CVE-2017-15115).

  Race condition in the ALSA subsystem in the Linux kernel before 4.13.8
  allows local users to cause a denial of service (use-after-free) or
  possibly have unspecified other impact via crafted /dev/snd/seq ioctl
  calls, related to sound/core/seq/seq_clientmgr.c and 
  sound/core/seq/seq_ports.c (CVE-2017-15265)

  The KEYS subsystem in the Linux kernel through 4.13.7 mishandles use of
  add_key for a key that already exists but is uninstantiated, which allows
  local users to cause a denial of service (NULL pointer dereference and
  system crash) or possibly have unspecified other impact via a crafted
  system call (CVE-2017-15299).

  The XFRM dump policy implementation in net/xfrm/xfrm_user.c in the Linux
  kernel before 4.13.11 allows local users to gain privileges or cause a
  denial of service (use-after-free) via a crafted SO_RCVBUF setsockopt
  system call in conjunction with XFRM_MSG_GETPOLICY Netlink messages
  (CVE-2017-16939).

  The walk_hugetlb_range function in mm/pagewalk.c in the Linux kernel
  before 4.14.2 mishandles holes in hugetlb ranges, which allows local
  users to obtain sensitive information from uninitialized kernel memory
  via crafted use of the mincore() system call (CVE-2017-16994).

  The check_alu_op function in kernel/bpf/verifier.c in the Linux kernel
  through 4.14.8 allows local users to cause a denial of service (memory
  corruption) or possibly have unspecified other impact by leveraging
  incorrect sign extension (CVE-2017-16995).

  kernel/bpf/verifier.c in the Linux kernel through 4.14.8 allows local
  users to cause a denial of service (memory corruption) or possibly have
  unspecified other impact by leveraging register truncation mishandling
  (CVE-2017-16996).

  kernel/bpf/verifier.c in the Linux kernel through 4.14.8 allows local
  users to cause a denial of service (memory corruption) or possibly have
  unspecified other impact by leveraging mishandling of 32-bit ALU ops
  (CVE-2017-17852).

  kernel/bpf/verifier.c in the Linux kernel through 4.14.8 allows local
  users to cause a denial of service (memory corruption) or possibly have
  unspecified other impact by leveraging incorrect BPF_RSH signed bounds
  calculations (CVE-2017-17853).

  kernel/bpf/verifier.c in the Linux kernel through 4.14.8 allows local
  users to cause a denial of service (integer overflow and memory
  corruption) or possibly have unspecified other impact by leveraging
  unrestricted integer values for pointer arithmetic (CVE-2017-17854).

  kernel/bpf/verifier.c in the Linux kernel through 4.14.8 allows local
  users to cause a denial of service (memory corruption) or possibly have
  unspecified other impact by leveraging improper use of pointers in
  place of scalars (CVE-2017-17855).

  kernel/bpf/verifier.c in the Linux kernel through 4.14.8 allows local
  users to cause a denial of service (memory corruption) or possibly
  have unspecified other impact by leveraging the lack of stack-pointer
  alignment enforcement (CVE-2017-17856).

  The check_stack_boundary function in kernel/bpf/verifier.c in the Linux
  kernel through 4.14.8 allows local users to cause a denial of service
  (memory corruption) or possibly have unspecified other impact by
  leveraging mishandling of invalid variable stack read operations
  (CVE-2017-17857).

  kernel/bpf/verifier.c in the Linux kernel through 4.14.8 ignores
  unreachable code, even though it would still be processed by JIT
  compilers. This behavior, also considered an improper branch-pruning
  logic issue, could possibly be used by local users for denial of
  service (CVE-2017-17862).

  kernel/bpf/verifier.c in the Linux kernel 4.9.x through 4.9.71 does not
  check the relationship between pointer values and the BPF stack, which
  allows local users to cause a denial of service (integer overflow or
  invalid memory access) or possibly have unspecified other impact
  (CVE-2017-17863).

  kernel/bpf/verifier.c in the Linux kernel before 4.14 mishandles
  states_equal comparisons between the pointer data type and the
  UNKNOWN_VALUE data type, which allows local users to obtain potentially
  sensitive address information, aka a "pointer leak" (CVE-2017-17864).

  The Linux Kernel 2.6.32 and later are affected by a denial of service,
  by flooding the diagnostic port 0x80 an exception can be triggered
  leading to a kernel panic (CVE-2017-1000407).

  For other changes in this update, read the referenced changelogs.
references:
 - https://bugs.mageia.org/show_bug.cgi?id=22269
 - https://kernelnewbies.org/Linux_4.10
 - https://kernelnewbies.org/Linux_4.11
 - https://kernelnewbies.org/Linux_4.12
 - https://kernelnewbies.org/Linux_4.13
 - https://kernelnewbies.org/Linux_4.14
 - https://cdn.kernel.org/pub/linux/kernel/v4.x/ChangeLog-4.14.1
 - https://cdn.kernel.org/pub/linux/kernel/v4.x/ChangeLog-4.14.2
 - https://cdn.kernel.org/pub/linux/kernel/v4.x/ChangeLog-4.14.3
 - https://cdn.kernel.org/pub/linux/kernel/v4.x/ChangeLog-4.14.4
 - https://cdn.kernel.org/pub/linux/kernel/v4.x/ChangeLog-4.14.5
 - https://cdn.kernel.org/pub/linux/kernel/v4.x/ChangeLog-4.14.6
 - https://cdn.kernel.org/pub/linux/kernel/v4.x/ChangeLog-4.14.7
 - https://cdn.kernel.org/pub/linux/kernel/v4.x/ChangeLog-4.14.8
 - https://cdn.kernel.org/pub/linux/kernel/v4.x/ChangeLog-4.14.9

Keywords: (none) => advisory

Started with
System:    Host: difda Kernel: 4.14.9-desktop-1.mga6 x86_64

Installed
kernel-linus-4.14.9-1.mga6-1-1.mga6
kernel-linus-devel-4.14.9-1.mga6-1-1.mga6
kernel-linus-devel-latest-4.14.9-1.mga6
kernel-linus-latest-4.14.9-1.mga6
kernel-linus-source-4.14.9-1.mga6-1-1.mga6
kernel-linus-source-latest-4.14.9-1.mga6

$ drakboot --boot
Rebooted to working desktop after building nvidia-current, vboxadditions and virtualbox kernel modules against the new kerenl.

System:    Host: difda Kernel: 4.14.9-1.mga6 x86_64 (64 bit)
CPU:       Quad core Intel Core i7-4790 (-HT-MCP-) speed/max: 3600/4000 MHz
Machine:   Device: desktop Mobo: MSI model: Z97-G43 (MS-7816) v: 3.0
           UEFI: American Megatrends v: V17.8 date: 12/24/2014
Graphics:  Card: NVIDIA GM204 [GeForce GTX 970]
           Resolution: 3840x2160@60.00hz
           GLX Version: 4.5.0 NVIDIA 384.98
RAM:       31.37 GB

Ran some tests, installed updates and tried out virtualbox.
stress -d failed to terminate (continuous respawning), which I think happened before, on this machine only (other systems have the same layout; / on a reserved multiboot SSD, ext4).  It disappears eventually.  'killall stress' has no apparent effect.
glxspheres64, NFS, ssh, glmark2, virtualbox running fine.

CC: (none) => tarazed25

Installed the linus kernel, updated the bootloader and rebooted.

System:    Host: markab Kernel: 4.14.9-1.mga6 x86_64 (64 bit)
CPU:       Quad core Intel Core i7-5700HQ (-HT-MCP-)
Machine:   Device: laptop System: GIGABYTE product: X5
           Mobo: GIGABYTE model: X5
Graphics:  Card-1: NVIDIA GM204M [GeForce GTX 965M]
           Card-2: NVIDIA GM204M [GeForce GTX 965M]
           Resolution: 2880x1620@59.96hz
           GLX Version: 4.5.0 NVIDIA 384.98

Ran stress tests and glmark2 and the usual checks on networking, NFS, sound and video.  Everything in order.  No vboxes set up on this machine.

Updated to 4.14.10 to fix a some regressions...

advisory updated

new rpms:

SRPMS:
kernel-linus-4.14.10-1.mga6.src.rpm


i586:
kernel-linus-4.14.10-1.mga6-1-1.mga6.i586.rpm
kernel-linus-devel-4.14.10-1.mga6-1-1.mga6.i586.rpm
kernel-linus-devel-latest-4.14.10-1.mga6.i586.rpm
kernel-linus-doc-4.14.10-1.mga6.noarch.rpm
kernel-linus-latest-4.14.10-1.mga6.i586.rpm
kernel-linus-source-4.14.10-1.mga6-1-1.mga6.noarch.rpm
kernel-linus-source-latest-4.14.10-1.mga6.noarch.rpm


x86_64:
kernel-linus-4.14.10-1.mga6-1-1.mga6.x86_64.rpm
kernel-linus-devel-4.14.10-1.mga6-1-1.mga6.x86_64.rpm
kernel-linus-devel-latest-4.14.10-1.mga6.x86_64.rpm
kernel-linus-doc-4.14.10-1.mga6.noarch.rpm
kernel-linus-latest-4.14.10-1.mga6.x86_64.rpm
kernel-linus-source-4.14.10-1.mga6-1-1.mga6.noarch.rpm
kernel-linus-source-latest-4.14.10-1.mga6.noarch.rpm

Summary: Update request: kernel-linus-4.14.9-1.mga6 => Update request: kernel-linus-4.14.10-1.mga6

System:    Host: vega Kernel: 4.14.10-1.mga6 x86_64
           Desktop: MATE 1.18.0  Distro: Mageia 6 mga6
CPU:       Quad core Intel Core i7-4790K (-HT-MCP-) speed/max: 4000/4400 MHz
Machine:   Device: desktop Mobo: Gigabyte model: G1.Sniper Z97 v: x.x
           UEFI: American Megatrends v: F6 date: 05/30/2014
Graphics:  Card-2: NVIDIA GK104 [GeForce GTX 770]
           GLX Renderer: GeForce GTX 770/PCIe/SSE2
           GLX Version: 4.5.0 NVIDIA 384.98
RAM:       15.35 GB

Installed the linus kernel packages.
$ drakboot --boot

Rebooted to a working desktop.  Ran the usual tests starting with
$ stress -c 4 -t 30
All worked as expected.  firefox and thunderbird running.

OK for 64 bits.

M6 x86 real EFI hardware, AMD/ATI/Radeon graphics

kernel-linus-4.14.10-1.mga6-1-1.mga6

After mixed usage, video & sound included, no problems. OK for me.

CC: (none) => lewyssmith

All kernels ok on my system, both under vb and on real hardware.

CC: (none) => davidwhodgins

Hardware tested: ASRock A790GXH128M motherboard, Athlon X2 7750 processor, 8GB RAM, Geforce 9800 GT graphics, Atheros wifi.

There are two Mageia 6 installs on this hardware, one 64-bit and one 32-bit, both using the server kernel, both using Plasma. Both installs had been updated to the 4.14.10 server kernel prior to these tests. In each test, the 4.14.10 kernel-linus was installed from scratch, not as an update to a previous kernel-linus.

The 64-bit install went well, no problems, no regressions noted. Wifi worked, videos played, Firefox browsed.

On the first attempt to install to 32-bit, the entire system froze before it finished. The only way to get out was by using the reset button. While I have nothing to back it up, my gut tells me this was probably a manifestation of the freeze-ups seen by others with Plasma, especially with nvidia. It just happened at a most inconvenient time. 

I then tried rebooting into the 4.14.10 server kernel, only to find that the rpm db had been trashed. After rebuilding it, I attempted to remove the kernel-linus packages that had been installed, so I could try again. This appeared to once again stall out, though the system itself didn't crash this time. After about 10 minutes, I once again rebooted, and once again the rpm db had been trashed.

Thinking that perhaps the 4.14.10 server kernel was reacting badly with Plasma and the nvidia driver, I rebooted again, this time into server kernel 4.9.56, and tried again. And again the entire system crashed.

Another reboot into kernel 4.9.56, and another rpm db rebuild. This time, believing Plasma to be the problem, I installed task-xfce and task-xfce-plugins. That went very well. Another reboot, this time into server kernel 4.14.10 and Xfce. And another attempt at installing kernel-linus. It took a long time, eventually appearing to stall out with a busy cursor. It may be, almost probably is, that I was too impatient, and I aborted things yet again. Had I waited a bit longer, it might have completed.

After another rpm db rebuild, and removing the packages that were listed as installed, I tried it one more time. This time, at the suggestion of tmb, I did a cold boot into server kernel 4.9.56, and into Xfce. This time I waited it out, and eventually the kernel-linus install completed successfully. 

Yet another reboot, this time into kernel-linus and again into Xfce. (The boot went too quickly for the nvidia module to have been built. Could it be using the one that had already been built during the install of server-kernel 4.14.10?) the system performed well, no problems or regressions noted.

My gut feeling is still that my original problem came from Plasma and the nvidia340 driver not getting along well with each other, a known upstream problem. I use this system very infrequently, actually only for testing, so I don't see what it might do with Plasma and extended use. This is the first time I've seen a freeze-up. With any luck, the problem will go away when we update to the next Plasma LTS.

I'd say, perhaps with a bit of caution where Plasma is concerned, that kernel-linus 4.14.10 is OK on this hardware, both 64-bit and 32-bit.

CC: (none) => andrewsfarm

Once installed on the above hardware, 32-bit kernel-linus seems to be OK with Plasma, too.

An update for this issue has been pushed to the Mageia Updates repository.

https://advisories.mageia.org/MGASA-2018-0064.html

Status: NEW => RESOLVED
Resolution: (none) => FIXED