Linux version 4.4.50-desktop-1.mga5 (iurt@ecosse.mageia.org) (gcc version 4.9.2 (GCC) ) #1 SMP Sat Feb 18 23:22:13 UTC 2017
My first impressions are positive, the kernel seems stable there seems to be no regressions, but in the next few hours I will test better
MGA5-64

CC: (none) => nathan95

After several tests the kernel seems stable on MGA5-64

Whiteboard: (none) => MGA5-64-OK

Holding off the validation for now. More testing on both arches preferred.

Keywords: validated_update => (none)
CC: (none) => davidwhodgins

Installed this on an x86_64 UEFI desktop machine.  nvidia GTX 770.Intel(R) Core(TM) i7-4790K CPU @ 4.00GHz
16 GB RAM
Disk storage: 2 SSDs, 2GB spinning rust

Clean install.  linus kernel clearly identified in the boot menu.
libafs, nvidia and virtualbox modules built during the boot sequence.
virtualbox works fine.  Watching Freeview TV in full HD using vlc.  Sound working via bluetooth.  Reporting this in firefox.  Remote login to production machine and ran gqview on a picture folder.  The images displayed perfectly, taking no more than a second to render.

So all is well but shall leave it running.

One happy note; this particular PC has always suffered from a strange hiatus when logging out and getting to the reboot screen even though it is a very fast machine - having to wait nearly two minutes was a constant annoyance.  Under the last two test kernels this hiatus seems to have disappeared.  Maybe something to do with the kernel firmware installed earlier.  The motherboard was intended by the PC manufacturer for gaming (Gigabyte Sniper Z.97) so there may be something odd in its settings, who knows?

CC: (none) => tarazed25

Only one fix added on top of already tested 4.4.50-1:
- dccp: fix freeing skb too early for IPV6_RECVPKTINFO (CVE-2017-6074)

Advisory will follow later today

SRPM:
kernel-linus-4.4.50-2.mga5.src.rpm

i586:
kernel-linus-4.4.50-2.mga5-1-1.mga5.i586.rpm
kernel-linus-devel-4.4.50-2.mga5-1-1.mga5.i586.rpm
kernel-linus-devel-latest-4.4.50-2.mga5.i586.rpm
kernel-linus-doc-4.4.50-2.mga5.noarch.rpm
kernel-linus-latest-4.4.50-2.mga5.i586.rpm
kernel-linus-source-4.4.50-2.mga5-1-1.mga5.noarch.rpm
kernel-linus-source-latest-4.4.50-2.mga5.noarch.rpm

x86_64:
kernel-linus-4.4.50-2.mga5-1-1.mga5.x86_64.rpm
kernel-linus-devel-4.4.50-2.mga5-1-1.mga5.x86_64.rpm
kernel-linus-devel-latest-4.4.50-2.mga5.x86_64.rpm
kernel-linus-doc-4.4.50-2.mga5.noarch.rpm
kernel-linus-latest-4.4.50-2.mga5.x86_64.rpm
kernel-linus-source-4.4.50-2.mga5-1-1.mga5.noarch.rpm
kernel-linus-source-latest-4.4.50-2.mga5.noarch.rpm

Priority: Normal => High
Summary: Update request: kernel-linus-4.4.50-1.mga5 => Update request: kernel-linus-4.4.50-2.mga5
Whiteboard: MGA5-64-OK MGA5-32-OK => (none)
Severity: normal => critical

Advisory text (also added to svn)


The cgroup offline implementation in the Linux kernel through 4.8.11
mishandles certain drain operations, which allows local users to cause
a denial of service (system hang) by leveraging access to a container
environment for executing a crafted application, as demonstrated by
trinity (CVE-2016-9191).

arch/x86/kvm/vmx.c in the Linux kernel through 4.9 mismanages the #BP
and #OF exceptions, which allows guest OS users to cause a denial of
service (guest OS crash) by declining to handle an exception thrown by
an L2 guest (CVE-2016-9588).

The sg implementation in the Linux kernel through 4.9 does not properly
restrict write operations in situations where the KERNEL_DS option is set,
which allows local users to read or write to arbitrary kernel memory
locations or cause a denial of service (use-after-free) by leveraging
access to a /dev/sg device, related to block/bsg.c and drivers/scsi/sg.c
(CVE-2016-10088).

The ext4_fill_super function in fs/ext4/super.c in the Linux kernel
through 4.9.8 does not properly validate meta block groups, which
allows physically proximate attackers to cause a denial of service
(out-of-bounds read and system crash) via a crafted ext4 image
(CVE-2016-10208).

The load_segment_descriptor implementation in arch/x86/kvm/emulate.c in
the Linux kernel before 4.9.5 improperly emulates a "MOV SS, NULL
selector" instruction, which allows guest OS users to cause a denial of
service (guest OS crash) or gain guest OS privileges via a crafted
application (CVE-2017-2583).

arch/x86/kvm/emulate.c in the Linux kernel through 4.9.3 allows local
users to obtain sensitive information from kernel memory or cause a
denial of service (use-after-free) via a crafted application that
leverages instruction emulation for fxrstor, fxsave, sgdt, and sidt
(CVE-2017-2584).

drivers/hid/hid-corsair.c in the Linux kernel 4.9.x before 4.9.6
interacts incorrectly with the CONFIG_VMAP_STACK option, which allows
local users to cause a denial of service (system crash or memory
corruption) or possibly have unspecified other impact by leveraging
use of more than one virtual page for a DMA scatterlist (CVE-2017-5547).

drivers/net/ieee802154/atusb.c in the Linux kernel 4.9.x before 4.9.6
interacts incorrectly with the CONFIG_VMAP_STACK option, which allows
local users to cause a denial of service (system crash or memory
corruption) or possibly have unspecified other impact by leveraging
use of more than one virtual page for a DMA scatterlist (CVE-2017-5548).

The klsi_105_get_line_state function in drivers/usb/serial/kl5kusb105.c
in the Linux kernel before 4.9.5 places uninitialized heap-memory
contents into a log entry upon a failure to read the line status, which
allows local users to obtain sensitive information by reading the log
(CVE-2017-5549).

The simple_set_acl function in fs/posix_acl.c in the Linux kernel before
4.9.6 preserves the setgid bit during a setxattr call involving a tmpfs
filesystem, which allows local users to gain group privileges by
leveraging the existence of a setgid program with restrictions on
execute permissions (CVE-2017-5551).

An issue was found in the Linux kernel ipv6 implementation of GRE tunnels
which allows a remote attacker to trigger an out-of-bounds access
(CVE-2017-5897).

The ipv4_pktinfo_prepare function in net/ipv4/ip_sockglue.c in the Linux
kernel through 4.9.9 allows attackers to cause a denial of service
(system crash) via (1) an application that makes crafted system calls or
possibly (2) IPv4 traffic with invalid IP options (CVE-2017-5970).

Race condition in the sctp_wait_for_sndbuf function in net/sctp/socket.c
in the Linux kernel before 4.9.11 allows local users to cause a denial
of service (assertion failure and panic) via a multithreaded application
that peels off an association in a certain buffer-full state
(CVE-2017-5986).

The dccp_rcv_state_process function in net/dccp/input.c in the Linux
kernel through 4.9.11 mishandles DCCP_PKT_REQUEST packet data structures
in the LISTEN state, which allows local users to obtain root privileges
or cause a denial of service (double free) via an application that makes
an IPV6_RECVPKTINFO setsockopt system call (CVE-2017-6074).

The tcp_splice_read function in net/ipv4/tcp.c in the Linux kernel before
4.9.11 allows remote attackers to cause a denial of service (infinite loop
and soft lockup) via vectors involving a TCP packet with the URG flag
(CVE-2017-6214).

Whiteboard: (none) => advisory

Installed this on an x86_64 UEFI machine on the mga5 partition but on reboot could not find it.  No sign of it anywhere in the boot menu.

I understand that the boot menu entry name might not correspond exactly with the name of the kernel but taking that into account none of the entries relate to the latest install.  This is something that has been happening a lot lately.  If it cannot be resolved then I shall be forced to give up testing kernels.

I have asked before; is my assumption that the boot menu is updated automatically correct?

That last question was prompted by the fact that the boot menu contained an entry for a deleted kernel which had no corresponding vmlinuz.

If in doubt try rescue.  The USB stick came to my aid and reloaded the bootloader.  The linus kernel is named in the boot menu now.

However, I do not want to insert a Rescue disk every time a new kernel is installed so what is the answer?

I have found that on systems where I have more than one mga installation I need to update Grub2 in the system that installed the boot-loader. I have adopted, instead, the practice of always running drakboot after adding or removing a kernel, thus re-installing the boot-loader. By default this will make that install the default in the Grub2 menu. There may be a technically more "correct" way of describing and handling this, but running drakboot always works for me. 

linus and tmb kernels appear in the "Advanced Options" menu.

My systems are all BIOS boot with GPT partitioned disks.

CC: (none) => jim

Thanks James.  I have been poking about and wondered if grub-update would work but seeing as drakboot works for you  I shall look into that.

One additional point, the linus kernel is identified in the boot menu only by its version number (no mention of linus). The tmb kernel is identified as such.

Yes, I remember that from previous installs, but after reinstalling the bootloader it comes up properly labelled in the boot menu.  On the desktop, as you say, it loses the linus tag.  

Seems to be working OK.  Shall run a few houskeeping checks and keep it running for a while.

on mga5-32 packages

- kernel-linus-4.4.50-2.mga5-1-1.mga5.i586
- kernel-linus-latest-4.4.50-2.mga5.i586

System booted normally
$ uname -r
4.4.50-2.mga5

No regressions noted

OK for mga5-32 on this system:
CPU: Quad core Intel Core i7-6700 
Graphics: Intel HD Graphics 530

on mga5-64 packages installed:

- kernel-linus-4.4.50-2.mga5-1-1.mga5.x86_64
- kernel-linus-latest-4.4.50-2.mga5.x86_64

System boots normally
[jim@mga5-64 ~]$ uname -r
4.4.50-2.mga5

No regressions noted

OK for mga5-64 on this system
CPU:  Quad core Intel Core i7-6700
Graphics: Intel HD Graphics 530

Validating the update

Keywords: (none) => validated_update
Whiteboard: advisory => advisory MGA5-64-OK MGA5-32-OK

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

http://advisories.mageia.org/MGASA-2017-0065.html

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