on mga6-64  kernel-desktop  plasma

packages installed cleanly:
- dkms-virtualbox-6.0.10-1.mga6.noarch
- virtualbox-6.0.10-1.mga6.x86_64
- virtualbox-kernel-4.14.131-desktop-1.mga6-6.0.10-1.mga6.x86_64
- virtualbox-kernel-desktop-latest-6.0.10-1.mga6.x86_64

# dkms status
virtualbox, 6.0.10-1.mga6, 4.14.131-desktop-1.mga6, x86_64: installed 
virtualbox, 6.0.10-1.mga6, 4.14.131-desktop-1.mga6, x86_64: installed-binary from 4.14.131-desktop-1.mga6

vbox launched normally
extension pack updated cleanly

updated vboxadditions on mga6-32 client which re-launched normally

no regressions noted

OK for mga6-64 on this system:

Machine:   Device: desktop System: Dell product: Precision Tower 3620
           Mobo: Dell model: 09WH54 v: A00 UEFI [Legacy]: Dell v: 2.13.1 
CPU:       Quad core Intel Core i7-6700 (-HT-MCP-)
Graphics:  Card: Intel HD Graphics 530

CC: (none) => jim

on mga7-64  kernel-desktop  plasma

packages installed cleanly:
- dkms-virtualbox-6.0.10-1.mga7.noarch
- virtualbox-6.0.10-1.mga7.x86_64
- virtualbox-kernel-5.1.18-desktop-1.mga7-6.0.10-1.mga7.x86_64
- virtualbox-kernel-desktop-latest-6.0.10-1.mga7.x86_64

# dkms status
virtualbox, 6.0.10-1.mga7, 5.1.18-1.mga7, x86_64: installed 
virtualbox, 6.0.10-1.mga7, 5.1.18-desktop-1.mga7, x86_64: installed-binary from 5.1.18-desktop-1.mga7

extension pack upgraded cleanly

vbox and client launched normally

Updated vboxadditions in a mga7-32 VM

looks OK for mga7-64 on this system:

Desktop System: Dell product: Precision Tower 362
Quad Core model: Intel Core i7-6700
Intel HD Graphics 530

Host system: HP Probook 6550b, i3, 8GB RAM, Intel graphics, Intel wifi, 64-bit M7 Plasma system.

packages installed cleanly:

- virtualbox-6.0.10-1.mga7.x86_64
- virtualbox-kernel-5.1.18-desktop-1.mga7-6.0.10-1.mga7.x86_64
- virtualbox-kernel-desktop-latest-6.0.10-1.mga7.x86_64

Extension pack downloaded/installed/upgraded using the GUI without incident. 

My Mageia guests on this machine had not been run since mid-April, so they will need extensive updates before I can report on them. However, I did run my Windows XP guest, and it updated its malware protection with no problem. But, when I went to try downloading and inserting the guest additions, I found that the "Devices" tab was disabled in the menu bar. I have no idea if this is from something I did before, or if it's coming from this update. Since I use the "Devices" tab more than any other, it seems strange to me either that I would have disabled it  or that Oracle would.

After re-activating the tab, I verified that Bug 24696 is still in effect, that the guest additions CD iso had to be downloaded and installed manually. However, once installed, everything seemed normal.

Looks OK for this test.

CC: (none) => andrewsfarm

Same host system as Comment 3, this time testing Mageia 6 guests.

Two Mageia 6 Plasma guests, one for each arch. The 32-bit guest is older, and had not been updated in some time. Before getting updates, it was still using guest additions from vbox 5.x. After downloading and installing pending updates, but before rebooting, I checked and the shared folders had been auto-mounted. This would be before installing the guest additions related to this bug.

After the reboot, shared folders were not auto-mounted. This is similar to what happened in Mageia 7 guests in Bug 24141. Apparently, the fix that was applied to Mageia 7 6.0.x guest additions was never applied to Mageia 6 6.0.x guest additions. Updating the guest additions in Mageia 6 to 6.0.10 does not fix the issue. Shared folders still do not auto-mount in Mageia 6.

Other than that, things look OK for Mageia 6 guests.

Same host system as Comment3, this time testing a Mageia 7 64-bit Plasma guest.

This guest had originally been created with an upgrade install from the Mageia 7 beta 3 iso. Guest additions were working. I used the Mageia 7.1 iso to upgrade this guest into an Official Mageia 7, then got all pending updates. Shared folders still auto-mounted.

After updating the guest additions to 6.0.10, and rebooting, shared folders still auto-mounted, and everything else looks good.

OK on this guest.

Tested on 7 64-bit mageia. I didn't notice any problems, the new version works perfectly

On real hardware, M7.1, Plasma, 64-bit

initial install:

kernel-desktop-latest
virtualbox dkms-virtualbox
virtualbox-guest-additions virtualbox-kernel-desktop-latest
x11-driver-video-vboxvideo kernel-desktop-devel-latest cpupower

The following 7 packages are going to be installed:

- dkms-virtualbox-6.0.8-1.mga7.noarch
- virtualbox-6.0.8-1.mga7.x86_64
- virtualbox-guest-additions-6.0.8-1.mga7.x86_64
- virtualbox-kernel-5.1.18-desktop-1.mga7-6.0.8-25.mga7.x86_64
- virtualbox-kernel-desktop-latest-6.0.8-25.mga7.x86_64
- x11-driver-video-vboxvideo-1.0.0-5.mga7.x86_64
- xrandr-1.5.0-2.mga7.x86_64

[root@localhost wilcal]# uname -a
Linux localhost 5.1.18-desktop-1.mga7 #1 SMP Sun Jul 14 10:08:39 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
[root@localhost wilcal]# urpmi kernel-desktop-latest
Package kernel-desktop-latest-5.1.18-1.mga7.x86_64 is already installed
[root@localhost wilcal]# urpmi virtualbox
Package virtualbox-6.0.8-1.mga7.x86_64 is already installed
[root@localhost wilcal]# urpmi dkms-virtualbox
Package dkms-virtualbox-6.0.8-1.mga7.noarch is already installed
[root@localhost wilcal]# urpmi virtualbox-guest-additions
Package virtualbox-guest-additions-6.0.8-1.mga7.x86_64 is already installed
[root@localhost wilcal]# urpmi x11-driver-video-vboxvideo
Package x11-driver-video-vboxvideo-1.0.0-5.mga7.x86_64 is already installed
[root@localhost wilcal]# urpmi kernel-desktop-devel-latest
Package kernel-desktop-devel-latest-5.1.18-1.mga7.x86_64 is already installed
[root@localhost wilcal]# urpmi cpupower
Package cpupower-5.1.18-1.mga7.x86_64 is already installed
[wilcal@localhost ~]$ lspci -k
01:00.0 VGA compatible controller: NVIDIA Corporation GF108 [GeForce GT 440] (rev a1)
        Subsystem: Gigabyte Technology Co., Ltd Device 3518
        Kernel driver in use: nvidia
        Kernel modules: nvidiafb, nouveau, nvidia_drm, nvidia390
        
Mageia-6.1-LiveDVD-Xfce-i586-DVD.iso
Create a Vbox client. Works just fine. Boots to a working desktop.

install from update_testing:

virtualbox dkms-virtualbox
virtualbox-guest-additions virtualbox-kernel-desktop-latest
x11-driver-video-vboxvideo kernel-desktop-devel-latest cpupower

The following 5 packages are going to be installed:

- dkms-virtualbox-6.0.10-1.mga7.noarch
- virtualbox-6.0.10-1.mga7.x86_64
- virtualbox-guest-additions-6.0.10-1.mga7.x86_64
- virtualbox-kernel-5.1.18-desktop-1.mga7-6.0.10-1.mga7.x86_64
- virtualbox-kernel-desktop-latest-6.0.10-1.mga7.x86_64

[root@localhost wilcal]# uname -a
Linux localhost 5.1.18-desktop-1.mga7 #1 SMP Sun Jul 14 10:08:39 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
[root@localhost wilcal]# urpmi kernel-desktop-latest
Package kernel-desktop-latest-5.1.18-1.mga7.x86_64 is already installed
[root@localhost wilcal]# urpmi virtualbox
Package virtualbox-6.0.10-1.mga7.x86_64 is already installed
[root@localhost wilcal]# urpmi dkms-virtualbox
Package dkms-virtualbox-6.0.10-1.mga7.noarch is already installed
[root@localhost wilcal]# urpmi virtualbox-guest-additions
Package virtualbox-guest-additions-6.0.10-1.mga7.x86_64 is already installed
[root@localhost wilcal]# urpmi x11-driver-video-vboxvideo
Package x11-driver-video-vboxvideo-1.0.0-5.mga7.x86_64 is already installed
[root@localhost wilcal]# urpmi kernel-desktop-devel-latest
Package kernel-desktop-devel-latest-5.1.18-1.mga7.x86_64 is already installed
[root@localhost wilcal]# urpmi cpupower
Package cpupower-5.1.18-1.mga7.x86_64 is already installed
[wilcal@localhost ~]$ lspci -k
01:00.0 VGA compatible controller: NVIDIA Corporation GF108 [GeForce GT 440] (rev a1)
        Subsystem: Gigabyte Technology Co., Ltd Device 3518
        Kernel driver in use: nvidia
        Kernel modules: nvidiafb, nouveau, nvidia_drm, nvidia390
        
Mageia-6.1-LiveDVD-Xfce-i586-DVD.iso
Still works as a Vbox client. Boots to a working desktop.

Mageia-7-Live-GNOME-x86_64.iso
Create a Vbox client. Works just fine. Boots to a working desktop.

Mageia-7-x86_64.iso   (M7.1)
Installs as a Vbox client. Boots to a working desktop.
Updates then reboots back to a working desktop.

Test platform:
Intel Core i7-2600K Sandy Bridge 3.4GHz
GIGABYTE GA-Z68X-UD3-B3 LGA 1155 MoBo
GIGABYTE GV-N440D3-1GI Nvidia GeForce GT 440 (Fermi) 1GB
RTL8111/8168B PCI Express 1Gbit Ethernet
DRAM 16GB (4 x 4GB)

CC: (none) => wilcal.int

Different hardware than Comment 5, Mageia 6 Plasma host. Same results as my other comments. Everything seems good except that Mageia 6 guests do not auto-mount shared folders, regardless of the host.

(In reply to Thomas Andrews from comment #4)
> Same host system as Comment 3, this time testing Mageia 6 guests.
> 
> After the reboot, shared folders were not auto-mounted. This is similar to
> what happened in Mageia 7 guests in Bug 24141. Apparently, the fix that was
> applied to Mageia 7 6.0.x guest additions was never applied to Mageia 6
> 6.0.x guest additions.

It is, and has been since 6.0.8.


 Updating the guest additions in Mageia 6 to 6.0.10
> does not fix the issue. Shared folders still do not auto-mount in Mageia 6.
> 


Is vboxadd-timesync enabled and running ?
If that still does not work, it means there is some upstream regression...


> Other than that, things look OK for Mageia 6 guests.

Since this is a security update, I'm wondering if we should push it anyway...

If not, we'll split the bugreport so we can push the mga7 update as I need to release a new mga7 kernel soon-ish.

Mageia 6, 64 bit:

Quick test booting an existing MSW7 guest, including manually installed extpack, USB stick working, video OK, Ethernet OK, Host File sharing OK, Screen rezising OK.

Hardware: i7-2600K, Nvidia GTX760 (GK104) using proprietary driver GeForce 420 and later.

This host system Mageia 6 is fully updated against testing.

CC: (none) => fri

(In reply to Thomas Backlund from comment #9)

> It is, and has been since 6.0.8.

So no regression in pushing this update actually, as I see it...

(even better if it get fixed, iff it do not take long)

(In reply to Thomas Backlund from comment #9)
> 
> 
> Is vboxadd-timesync enabled and running ?
> If that still does not work, it means there is some upstream regression...
> 
According to the guest's MCC, yes. It is set to start at boot.
> 
> > Other than that, things look OK for Mageia 6 guests.
> 
> Since this is a security update, I'm wondering if we should push it anyway...
> 
> If not, we'll split the bugreport so we can push the mga7 update as I need
> to release a new mga7 kernel soon-ish.

Since this was happening with vbox 6.0.8 as well (in my M6 guests, anyway), and nobody has complained but me, we could push it for both anyway, and I can file a new bug about this issue on M6 after it goes out. 

If it is an upstream regression, it's quite possible that it won't be fixed before M6 goes EOL, and IMO it's probably best not to hold the rest of vbox up because of that.

Agreed, this needs to be moved along.

This update is now validated

The Advisory needs to be uploaded to SVN

CC: (none) => sysadmin-bugs
Keywords: (none) => validated_update

Advisory, added to svn:

type: security
subject: Updated virtualbox packages fix security vulnerabilities
CVE:
 - CVE-2019-1543
 - CVE-2019-2848
 - CVE-2019-2850
 - CVE-2019-2859
 - CVE-2019-2863
 - CVE-2019-2864
 - CVE-2019-2865
 - CVE-2019-2866
 - CVE-2019-2867
 - CVE-2019-2873
 - CVE-2019-2874
 - CVE-2019-2875
 - CVE-2019-2876
 - CVE-2019-2877
src:
  6:
   core:
     - virtualbox-6.0.10-1.mga6
     - kmod-virtualbox-6.0.10-1.mga6
     - kmod-vboxadditions-6.0.10-1.mga6
  7:
   core:
     - virtualbox-6.0.10-1.mga7
     - kmod-virtualbox-6.0.10-1.mga7
description: |
  OpenSSL versions 1.1.0 through 1.1.0j and 1.1.1 through 1.1.1b are
  susceptible to a vulnerability that could lead to disclosure of sensitive
  information or the addition or modification of data (CVE-2019-1543).

  Oracle VM VirtualBox prior to 6.0.10 has an easily exploitable vulnerability
  that allows low privileged attacker with logon to the infrastructure where
  Oracle VM VirtualBox executes to compromise Oracle VM VirtualBox. While the
  vulnerability is in Oracle VM VirtualBox, attacks may significantly impact
  additional products. Successful attacks of this vulnerability can result in
  unauthorized ability to cause a hang or frequently repeatable crash
  (complete DOS) of Oracle VM VirtualBox (CVE-2019-2848).

  Oracle VM VirtualBox prior to 6.0.10 has an easily exploitable vulnerability
  that allows low privileged attacker with logon to the infrastructure where
  Oracle VM VirtualBox executes to compromise Oracle VM VirtualBox. Successful
  attacks require human interaction from a person other than the attacker.
  Successful attacks of this vulnerability can result in unauthorized ability
  to cause a partial denial of service (partial DOS) of Oracle VM VirtualBox
  (CVE-2019-2850).

  Oracle VM VirtualBox prior to 6.0.10 has an easily exploitable vulnerability
  that allows low privileged attacker with logon to the infrastructure where
  Oracle VM VirtualBox executes to compromise Oracle VM VirtualBox. While the
  vulnerability is in Oracle VM VirtualBox, attacks may significantly impact
  additional products. Successful attacks of this vulnerability can result in
  takeover of Oracle VM VirtualBox (CVE-2019-2859).

  Oracle VM VirtualBox prior to 6.0.10 has an easily exploitable vulnerability
  that allows low privileged attacker with logon to the infrastructure where
  Oracle VM VirtualBox executes to compromise Oracle VM VirtualBox. While the
  vulnerability is in Oracle VM VirtualBox, attacks may significantly impact
  additional products. Successful attacks of this vulnerability can result in
  unauthorized access to critical data or complete access to all Oracle VM
  VirtualBox accessible data (CVE-2019-2863).

  Oracle VM VirtualBox prior to 6.0.10 has a difficult to exploit
  vulnerability allows high privileged attacker with logon to the
  infrastructure where Oracle VM VirtualBox executes to compromise Oracle
  VM VirtualBox. While the vulnerability is in Oracle VM VirtualBox, attacks
  may significantly impact additional products. Successful attacks of this
  vulnerability can result in takeover of Oracle VM VirtualBox
  (CVE-2019-2864, CVE-2019-2865).

  Oracle VM VirtualBox prior to 6.0.10 has an easily exploitable vulnerability
  allows high privileged attacker with logon to the infrastructure where
  Oracle VM VirtualBox executes to compromise Oracle VM VirtualBox. While the
  vulnerability is in Oracle VM VirtualBox, attacks may significantly impact
  additional products. Successful attacks of this vulnerability can result in
  takeover of Oracle VM VirtualBox (CVE-2019-2866, CVE-2019-2867).

  Oracle VM VirtualBox prior to 6.0.10 has an easily exploitable vulnerability
  that allows low privileged attacker with logon to the infrastructure where
  Oracle VM VirtualBox executes to compromise Oracle VM VirtualBox. Successful
  attacks of this vulnerability can result in unauthorized ability to cause a
  partial denial of service (partial DOS) of Oracle VM VirtualBox
  (CVE-2019-2873, CVE-2019-2874, CVE-2019-2875, CVE-2019-2876, CVE-2019-2877).
references:
 - https://bugs.mageia.org/show_bug.cgi?id=25161
 - https://www.oracle.com/technetwork/security-advisory/cpujul2019-5072835.html#AppendixOVIR
[tmb@tmb-laptop advisories]$

Keywords: (none) => advisory

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

https://advisories.mageia.org/MGASA-2019-0216.html

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