In a Vbox client, M5.1, KDE, 32-bit

Testing: kernel-tmb-desktop-latest

[root@localhost wilcal]# uname -a
Linux localhost 4.4.79-tmb-desktop-1.mga5 #1 SMP PREEMPT Fri Jul 28 12:01:24 UTC 2017 i686 i686 i686 GNU/Linux
[root@localhost wilcal]# urpmi kernel-tmb-desktop-latest
Package kernel-tmb-desktop-latest-4.4.79-1.mga5.i586 is already installed

Boots to a working desktop. Screen resolution is correct. Common apps work.

CC: (none) => wilcal.int

In a Vbox client, M5.1, KDE, 64-bit

Testing: kernel-tmb-latest

[root@localhost wilcal]# uname -a
Linux localhost 4.4.79-tmb-desktop-1.mga5 #1 SMP PREEMPT Fri Jul 28 11:54:07 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
[root@localhost wilcal]# urpmi kernel-tmb-desktop-latest
Package kernel-tmb-desktop-latest-4.4.79-1.mga5.x86_64 is already installed

Boots to a working desktop. Screen resolution is correct. Common apps work.

mga5  x86_64
Gigabyte Sniper Z.97
Intel Core i7-4790K 4.00GHz
nvidia GeForce GTX 770
multiboot UEFI

The three (6) tmb packages installed cleanly.

tmb kernel not listed in any of the grub2 entries so it was necessary to login and reinstall the bootloader.
Rebooted OK after rebuilding the nvidia, vboxadditions and virtualbox modules.  Mate desktop came up OK.
$ uname -r
4.4.79-tmb-desktop-1.mga5

Leaving this running for 24 hours.

CC: (none) => tarazed25

subject: Updated kernel-tmb packages fixes security and other bugs
CVE:
 - CVE-2017-10810
src:
  5:
   core:
     - kernel-tmb-4.4.79-1.mga5
description: |
  This kernel-tmb update is based on upstream 4.4.79 and fixes atleast the
  following security issues:

  Linux kernel built with the VirtIO GPU driver(CONFIG_DRM_VIRTIO_GPU) support
  is vulnerable to a memory leakage issue. It could occur while creating a
  virtio gpu object in virtio_gpu_object_create(). A user/process could use
  this flaw to leak host kernel memory potentially resulting in Dos
  (CVE-2017-10810).

  It also contains followup fixes to the Stack Clash (CVE-2017-1000370,
  CVE-2017-1000371) security issues resolved in kernels released at end
  of June, 2017.

  For other upstream fixes in this update, read the referenced changelogs.
references:
 - https://bugs.mageia.org/show_bug.cgi?id=21392
 - https://cdn.kernel.org/pub/linux/kernel/v4.x/ChangeLog-4.4.75
 - https://cdn.kernel.org/pub/linux/kernel/v4.x/ChangeLog-4.4.76
 - https://cdn.kernel.org/pub/linux/kernel/v4.x/ChangeLog-4.4.77
 - https://cdn.kernel.org/pub/linux/kernel/v4.x/ChangeLog-4.4.78
 - https://cdn.kernel.org/pub/linux/kernel/v4.x/ChangeLog-4.4.79

Whiteboard: (none) => advisory

tmb see comment 3 please.

(In reply to Len Lawrence from comment #3)
> 
> tmb kernel not listed in any of the grub2 entries so it was necessary to
> login and reinstall the bootloader.

IIUC this is normal behaviour on a multi-boot system, if the existing boot-loader was installed by a different installation than the one in which you installed the new kernel. To be certain, I always run drakboot after installing a new kernel in a multi-boot system. This causes the boot-loader to be updated.

CC: (none) => jim

(In reply to James Kerr from comment #6)

> 
> IIUC this is normal behaviour on a multi-boot system, if the existing
> boot-loader was installed by a different installation than the one in which
> you installed the new kernel. To be certain, I always run drakboot after
> installing a new kernel in a multi-boot system. This causes the boot-loader
> to be updated.

To be clear by "run drakboot" I mean use "MCC - Boot - Set up boot system" or run 'drakboot --boot' from the CLI. In Mageia 5 there is an anomaly in that 'drakboot' without the --boot parameter actually launches drakautologin.

(In reply to claire robinson from comment #5)
> tmb see comment 3 please.

as pointed out in comment 6, there is nothing kernel-tmb package can do here.

all kernels call the same /sbin/installkernel that takes care of updating the boot menus, but if an other distro install manages boot menus it can fail...

It could maybe be fixed/enhanced, but that is up to bootloader-utils & drakxtools-backend to handle...

An other way would be to fix grub2 to use the vmlinuz-tmb-$flavour and initrd-tmb-$flavour.img as default entries for tmb kernels as they will always point at last installed kernel-tmb-$flavour ...

Whiteboard: advisory feedback => advisory

On mga5-64

Packages installed cleanly:

- dkms-2.0.19-34.1.mga5.noarch
- dkms-virtualbox-5.1.26-1.mga5.noarch
- gcc-4.9.2-4.1.mga5.x86_64
- gcc-cpp-4.9.2-4.1.mga5.x86_64
- glibc-devel-2.20-25.mga5.x86_64
- kernel-desktop-devel-4.4.68-1.mga5-1-1.mga5.x86_64
- kernel-desktop-devel-4.4.79-1.mga5-1-1.mga5.x86_64
- kernel-desktop-devel-latest-4.4.79-1.mga5.x86_64
- kernel-tmb-desktop-4.4.79-1.mga5-1-1.mga5.x86_64
- kernel-tmb-desktop-latest-4.4.79-1.mga5.x86_64
- kernel-userspace-headers-4.4.79-1.mga5.x86_64
- lib64mpc3-1.0.2-4.mga5.x86_64
- lib64ncurses-devel-5.9-21.mga5.x86_64
- libstdc++5-3.3.6-11.mga5.x86_64
- libstdc++5-devel-3.3.6-11.mga5.x86_64
- kernel-tmb-desktop-devel-4.4.79-1.mga5-1-1.mga5.x86_64
- kernel-tmb-desktop-devel-latest-4.4.79-1.mga5.x86_64

Executed drakboot to re-install the boot-loader

The default "Mageia" entry in the boot menu used the command line, quoting from grub.cfg:

 linux   /boot/vmlinuz-tmb-desktop root=UUID=8393d454-d88c-4204-9d9d-bc9e5511fd96 ro   splash quiet noiswmd resume=UUID=82bfcb29-3f53-4b0b-8015-78c674b957a3
        echo    'Loading initial ramdisk ...'
        initrd  /boot/initrd-desktop.img

I think the initrd should be /boot/initrd-4.4.79-tmb-desktop-1.mga5.img

Although the system booted successfully from that menu entry to kernel-tmb, for all further testing I used the Advanced option which has, again quoting from  grub.cfg:

linux   /boot/vmlinuz-4.4.79-tmb-desktop-1.mga5 root=UUID=8393d454-d88c-4204-9d9d-bc9e5511fd96 ro   splash quiet noiswmd resume=UUID=82bfcb29-3f53-4b0b-8015-78c674b957a3
                echo    'Loading initial ramdisk ...'
                initrd  /boot/initrd-4.4.79-tmb-desktop-1.mga5.img

$ uname -r
4.4.79-tmb-desktop-1.mga5

I saw no problems running this kernel.

Virtualbox and a client launched successfully.

With the exception of the oddity with the default "Mageia" boot menu entry this is OK for mga5-64 on this system:

Dell product: Precision Tower 3620
Mobo: Dell model: 09WH54 
Card: Intel HD Graphics 530
CPU: Quad core Intel Core i7-6700 (-HT-MCP-)
PC-BIOS boot
GPT partitions

On mga5-32 in a vbox VM

Packages installed cleanly:

- kernel-tmb-desktop-4.4.79-1.mga5-1-1.mga5.i586
- kernel-tmb-desktop-devel-4.4.79-1.mga5-1-1.mga5.i586
- kernel-tmb-desktop-devel-latest-4.4.79-1.mga5.i586
- kernel-tmb-desktop-latest-4.4.79-1.mga5.i586

In order to boot this kernel, I had to enable PAE in the VM (I only had the desktop kernel installed in this VM previously)

The default "Mageia" entry in the Grub2 boot menu exhibited the same anomaly as  described in comment#9

VM booted normally from the Advanced option

$ uname -r
4.4.79-tmb-desktop-1.mga5

No problems observed

OK for mga5-32 in a vbox VM

(In reply to James Kerr from comment #9)
> 
> The default "Mageia" entry in the boot menu used the command line, quoting
> from grub.cfg:
> 
>  linux   /boot/vmlinuz-tmb-desktop
> root=UUID=8393d454-d88c-4204-9d9d-bc9e5511fd96 ro   splash quiet noiswmd
> resume=UUID=82bfcb29-3f53-4b0b-8015-78c674b957a3
>         echo    'Loading initial ramdisk ...'
>         initrd  /boot/initrd-desktop.img
> 
> I think the initrd should be /boot/initrd-4.4.79-tmb-desktop-1.mga5.img
> 

In fact, to be consistent with the vmlinuz the initrd should probably use the symlink  /boot/initrd-tmb-desktop.img

FWIW after removing kernel-tmb-desktop, I had to manually delete the dead "tmb" symlinks in /boot and run drakboot again in order to have the correct vmlinuz file used in the default "Mageia" entry in the boot menu.

It's tested enough to validate... 

I need theese out of the way as I need to start releasing new kernels for test as there is a new root exploit on the way...

Added OK for mga5-32 and validated

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

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

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

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