Hi, thanks for reporting this.
Assigned to recent commiters.

(Please set the status to 'assigned' if you are working on it)

Assignee: bugsquad => pkg-bugs
CC: (none) => ghibomgx, nicolas.salguero, ouaurelien, thierry.vignaud
Keywords: (none) => Triaged

Note:
- 6.0 branch is EOL upstream since last summer.
- as of 6.1 series, virtualbox only supports x86_64 hosts, so ...

Advisory will follow... we also need to add info about 64bit only support (not that I think there are many(any?) vbox host users that use 32bit anymore...

SRPMS:
virtualbox-6.1.16-1.mga7.src.rpm
kmod-virtualbox-6.1.16-1.mga7.src.rpm

x86_64:
dkms-vboxadditions-6.1.16-1.mga7.noarch.rpm
dkms-virtualbox-6.1.16-1.mga7.noarch.rpm
python-virtualbox-6.1.16-1.mga7.x86_64.rpm
virtualbox-6.1.16-1.mga7.x86_64.rpm
virtualbox-devel-6.1.16-1.mga7.x86_64.rpm
virtualbox-guest-additions-6.1.16-1.mga7.x86_64.rpm
virtualbox-kernel-5.7.19-desktop-3.mga7-6.1.16-1.mga7.x86_64.rpm
virtualbox-kernel-5.7.19-server-3.mga7-6.1.16-1.mga7.x86_64.rpm
virtualbox-kernel-desktop-latest-6.1.16-1.mga7.x86_64.rpm
virtualbox-kernel-server-latest-6.1.16-1.mga7.x86_64.rpm



And this one needs to be tested and validated/pushed before we can build kmods for kernel 5.9 series

Assignee: pkg-bugs => qa-bugs

This replace 5.7 smoothly.  Lauched two instances of virtualbox in separate workspaces, Mageia i686 client and an x64 client.  No problems with either.

CC: (none) => tarazed25

OK: mga7-64, Plasma, nvidia-current, 5.6.14-desktop-2.mga7
Machine Mainboard: Sabertooth P67, CPU: i7-3770, RAM 16G, Nvidia GM107 [GeForce GTX 750]
Guest: MSW7p-64

Other updates from testing installed: mesa, firmware, microcode

Upgraded VirtualBox from 6.0.24

Downloaded extension pack and guest additions from https://download.virtualbox.org/virtualbox/6.1.16/

Per bug Bug 18962, I install Oracle extension pack manually.

Booted my existing MSW7p-64 guest.  Tests OK:
  Gave it the extension pack in the "optical drive", installed, reboot.
  Dynamically resizing guest window by mouse
  Shared clipboard, bidirectional
  Shared folders bidirectional copying
  USB2: flash stick read and write
  Sound, Internet, performance: playing video in Firefox while host is heavily loaded  (at very high load the sound is a bit scratchy, normal)

CC: (none) => fri

on mga7-64  kernel-desktop  plasma

packages installed cleanly:
- dkms-virtualbox-6.1.16-1.mga7.noarch
- virtualbox-6.1.16-1.mga7.x86_64
- virtualbox-kernel-5.7.19-desktop-3.mga7-6.1.16-1.mga7.x86_64
- virtualbox-kernel-desktop-latest-6.1.16-1.mga7.x86_64

# dkms status
virtualbox, 6.1.16-1.mga7, 5.7.19-desktop-3.mga7, x86_64: installed 
virtualbox, 6.1.16-1.mga7, 5.7.19-desktop-3.mga7, x86_64: installed-binary from 5.7.19-desktop-3.mga7

vbox and clients (mga7-32, winxp, win7) launched normally

extension pack updated cleanly

updated additions in all clients 
 
No regressions observed.

looks OK 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 (legacy) boot
GPT partitions

CC: (none) => jim

Host hardware: Intel i5-2500, 16GB RAM, Intel graphics, wired Internet connection.

The following 3 packages are going to be installed:

- virtualbox-6.1.16-1.mga7.x86_64
- virtualbox-kernel-5.7.19-desktop-3.mga7-6.1.16-1.mga7.x86_64
- virtualbox-kernel-desktop-latest-6.1.16-1.mga7.x86_64

13MB of disk space will be freed.

No installation issues. As usual, my install was unaffected by Bug 18962. After downloading the extension pack manually, all I had to do was click on the pack file and follow the prompts.

Ran my aging yet still stable Windows XP guest, and found that Bug 24696 has apparently been solved upstream. I was able to download and update/upgrade the guest additions by using "Insert Guest Additions" from the "Devices" tab of the VirtualBox GUI.

Unfortunately, at the moment I don't have a Mageia 7 guest on this install. I shall endeavor to correct that oversight soon.

Running a Cauldron guest that hasn't been run in months, and am presently in the process of getting 1400+ updates that are waiting. No problems with the display size - yet.

So far, looks OK on this hardware.

CC: (none) => andrewsfarm

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

Package(s) under test:
virtualbox

[root@localhost wilcal]# uname -a
Linux localhost 5.7.19-desktop-3.mga7 #1 SMP Sun Oct 18 15:46:00 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
[root@localhost wilcal]# urpmi virtualbox
Package virtualbox-6.0.24-1.mga7.x86_64 is already installed

M7.1 i586 Xfce Live-DVD works just fine as a client
M7.1 x86_64 Plasma updating works just fine as a client

install from updates testing:

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


The following 9 packages are going to be installed:

- cpupower-5.9.11-3.mga7.x86_64
- dkms-vboxadditions-6.1.16-1.mga7.noarch
- dkms-virtualbox-6.1.16-1.mga7.noarch
- kernel-desktop-devel-5.9.11-3.mga7-1-1.mga7.x86_64
- kernel-desktop-devel-latest-5.9.11-3.mga7.x86_64
- virtualbox-6.1.16-1.mga7.x86_64
- virtualbox-guest-additions-6.1.16-1.mga7.x86_64
- virtualbox-kernel-5.7.19-desktop-3.mga7-6.1.16-1.mga7.x86_64
- virtualbox-kernel-desktop-latest-6.1.16-1.mga7.x86_64

[root@localhost wilcal]# uname -a
Linux localhost 5.7.19-desktop-3.mga7 #1 SMP Sun Oct 18 15:46:00 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
[root@localhost wilcal]# urpmi virtualbox
Package virtualbox-6.1.16-1.mga7.x86_64 is already installed

M7.1 i586 Xfce Live-DVD works just fine as a client
M7.1 x86_64 Plasma updating works just fine as a client
M8 x86_64 Plasma upating works just fine as a client

CC: (none) => wilcal.int

Host hardware Intel Core i5 6600K, with Nvidia Geforce GTX 1660 Ti.
This is a M7 x86_64 with 16 Go Ram.

Nvidia-current drivers in action.

$ uname -a
Linux mageia1 5.7.19-desktop-3.mga7 #1 SMP Sun Oct 18 15:46:00 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

(note that kernel-desktop-5.9.11-3.mga7 is already installed but not booted.)

from updates_testing:
urpmi dkms-vboxadditions dkms-virtualbox virtualbox-guest-additions virtualbox-kernel-desktop-latest x11-driver-video-vboxvideo virtualbox

Installation is OK.
Client M7.1 32bit Plasma/Gnome/XFCE are OK.
Client M7.1 x86_64 Plasma is OK.
Client Cauldron Plasma x86_64 is OK

Whenever Kernel-desktop-5.9.11-3.mga3 is booted,
Client M7.1 32bit Plasma/Gnome/XFCE are OK.
Client M7.1 x86_64 Plasma is OK.
Client Cauldron Plasma x86_64 is OK.

Note that I must use "VboxSVGA" driver mode in each Virtualbox VM Configuration to have a working Client resolution at 1440x900 for example.
With default VMSVGA, Plasma always goes back to 800x600 resolution.
See: https://bugs.mageia.org/show_bug.cgi?id=27323
https://bugs.mageia.org/show_bug.cgi?id=26872

For QT File I/O selecting ISO for CDROM drive in VM Configuration,
See also: https://bugs.mageia.org/show_bug.cgi?id=27433

Created a new M7 Plasma guest on the host from Comment 6, using the M7.1 netinstall iso. Though I haven't yet proceeded beyond the first boot, I can confirm that it seems to be working so far. 

As noted in Comment 8, "VboxSVGA" was required to have any resolution beyond 800x600.

It should be noted that in vbox 6.1.16, any change of the graphics controller from the one "recommended" by vbox will show a message in the settings for that device of "Invalid settings detected." This is true of any guest. My Windows XP guest uses "VboxVGA," and if you change that to anything else you see the message. Same thing with a Windows 7 guest I've been playing with, except that the recommended setting is "VboxSVGA." 

While this doesn't seem harmful, it will probably confuse many users, especially those new to vbox.

(In reply to Thomas Andrews from comment #9)
> 
> As noted in Comment 8, "VboxSVGA" was required to have any resolution beyond
> 800x600.

After a couple of guest reboots, a graphics controller setting of "VboxVGA" also provide additional resolutions.

Host: AMD Phenom II X4, 8GB RAM, AMD HD 8490 graphics, Atheros wifi, 64-bit Plasma system.

Guests: 1 Windows XP, 2 M7 64-bit Plasma, 1 M7 64-bit Xfce.

Packages installed cleanly, and the extension pack installed using the GUI. XP guest additions downloaded and installed using the Vbox GUI. Guest additions updated cleanly in all Mageia guests using QARepo.

After a "cold" reboot of each guest, each one functioned normally. Bidirectional clipboard functioned as expected. Multiple resolutions were available using both "VboxSVGA" and "VboxVGA" graphics controllers, but not with "VMSVGA."

Looks OK on this hardware.

Several tests now, with no issues noted. I'm giving this an OK, and validating. An advisory still needs to be crafted, and "Triaged" has to be removed from the Keywords, if appropriate. 

Also, the issue in Bug 27219 appears to have been addressed, so that can probably be marked as fixed.

Keywords: (none) => validated_update
CC: (none) => sysadmin-bugs
Whiteboard: (none) => MGA7-64-OK

Wait a minute - not so fast. Shouldn't there be a 32-bit equivalent to 

virtualbox-guest-additions-6.1.16-1.mga7.x86_64.rpm?

I can't find one, and neither can QARepo. I checked my 32-bit M7 Plasma guest, and it says the 6.0.24 guest additions are still installed. They seem to be working OK with vbox 6.1.16, for now, bidirectional clipboard, shared folders, display size, and USB 2.0 all working, but looks can be deceiving.

Keywords: validated_update => (none)
Whiteboard: MGA7-64-OK => (none)

And another question: If 32-bit host support has been dropped for the 6.1 series, why do we have a dkms-virtualbox-6.1.16-1.mga7.noarch.rpm and the pre-built host kmods in the 32-bit repos? They aren't used in the guests.

I'm suddenly quite confused.

No. 32 bit guests are supported, but not vb on a 32 bit host. See comment 2.

CC: (none) => davidwhodgins

The package are still built for all arches, even if they can not work due to
the way the build system works.

(In reply to Dave Hodgins from comment #16)
> No. 32 bit guests are supported, but not vb on a 32 bit host. See comment 2.

Yes, I read it before starting my tests. 

But as I have always understood it, guest additions are for and installed in the guest, not the host. So if 32-bit guests are supported, aren't 32-bit guest additions still supported, too? 

I had no problem getting what Oracle claimed are updated guest additions for my 32-bit Windows XP guest.

With regard to my Comment 15, the build system has always been about ten steps above my pay grade, so it's no surprise that I would have been confused on that point. Sorry for that noise.

(In reply to Dave Hodgins from comment #8)
> Got it to work. First make sure the user is a member of the vboxusers group.
Note from comment #8 in Bug 27323 from David Hodgins:
> Logout/in after any group change for that to take effect.
> 
> As root. run "chgrp vboxusers /dev/vbox*", and "chmod g+rw /dev/vbox*".
> 
> Then, using the VMSVGA display driver, started the client with 7.1 x86_64
> installed. After login, restored the dialog box containing the guest display
> using the down arrow near the top right of that dialog, then maximized it.
> The guest resized to match, as normal.
> 
> Shutdown and restarted the guest to confirm the resized display stuck, which
> it did.
> 
> So it's a permissions problem in the virtualbox rpm. Found it based on
> http://www.mgreene.org/?cat=39 though that fix alone is not enough.

Doing this give a working Console resolution to Mageia UEFI VM and also BIOS VM.
Note that sddm displays itself correctly to the size of the window VM.
But as soon as Plasma is launched, the resolution switches to 800x600 and trying to set it to a higher one results to a set back to 800x600.

Note that GNOME (Wayland and X11 session of M7 Client) can have good resolution screen.
I do think this is a kscreen in M7 sort-of bug.

Just a few questions/note. Does the flip/flop on resolution changing happens only on plasma, or on any desktop? What if you change the display resolution manually with xrandr? E.g. xrandr -s 1024x768 (or from resolution allowed from the list achived by simple running 'xrandr').

Regarding the display drivers, in VBox 6.1 the default display driver for Linux guest changed from "VBoxVGA" to "VMSVGA". The VBoxVGA in the Linux guests corresponds to use the driver "modesetting" or "vboxvideo". Newer guest can't use the VBoxVGA driver, because it's forced to use VMSVGA, but if you have older linux guests created with and older VBox that were configured to use the VBoxVGA they would continue to work: e.g. you created a mageia6 guest some time ago, it would use the old VBoxVGA driver (let's say compatibility is maintained).

The newer VMSVGA instead uses the "vmware" driver inside the Linux guest. It can or can't have the 3D acceleration. If you don't enable the 3d acceleration, mesa would use the "llvmpipe", with OpenGL 3.3 level compatibility. If you use the 3D acceleration, mesa would use the vmwgfx driver and there will be a speedup by 10-20x times, but the compatibility level would drop to OpenGL 2.1. Note that vmwgfx driver itself of mesa is capable of a higher GL compat level, in fact under VMwarePlayer vmwgfx would show OpenGL 4.1 compatibility level in 3D acceleration mode, but current virtualbox vmsgva driver is problaby not able to reach higher GL compat levels.

VBoxSVGA (and not VBoxVGA) is instead used for Windows guests only.

Regarding the 32 bit virtualbox guest additions, what you found is true, since we don't have anymore are 32 bit virtualbox package, and we built the 32bit virtualbox-additions as subpackages from the virtualbox package, there won't be automatic any 32bit virtualbox-additions RPM packages for linux guests (you can have for instance a 32bit linux guest inside a 64bit native linux machine). However 32bit virtualbox-additions for Linux do exists; if you take the upstream guestadditions ISO, e.g.from here:

https://download.virtualbox.org/virtualbox/6.1.16/VBoxGuestAdditions_6.1.16.iso

you'll see that the ./VBoxLinuxAdditions.run --list would show the file ./VBoxGuestAdditions-x86.tar.bz2 which are the guest additions for 32bit. I think it can be installed on 32bit linux guests outside RPM.

At most we could try to repackage it, or try to rebuild the 32bit virtualbox additions outside the Virtualbox package.

(In reply to Giuseppe Ghibò from comment #20)
> 
> Regarding the 32 bit virtualbox guest additions, what you found is true,
> since we don't have anymore are 32 bit virtualbox package, and we built the
> 32bit virtualbox-additions as subpackages from the virtualbox package, there
> won't be automatic any 32bit virtualbox-additions RPM packages for linux
> guests (you can have for instance a 32bit linux guest inside a 64bit native
> linux machine). However 32bit virtualbox-additions for Linux do exists; if
> you take the upstream guestadditions ISO, e.g.from here:
> 
> https://download.virtualbox.org/virtualbox/6.1.16/VBoxGuestAdditions_6.1.16.
> iso
> 
> you'll see that the ./VBoxLinuxAdditions.run --list would show the file
> ./VBoxGuestAdditions-x86.tar.bz2 which are the guest additions for 32bit. I
> think it can be installed on 32bit linux guests outside RPM.
> 
I had already downloaded the guest additions iso for my XP guest, and have been playing with it a bit...

First off, the 6.0.24 guest additions are not quite right with regard to the size of the display. If I have the guest window maximized, when I boot the 32-bit guest up the guest is 800x600 within it, but if I un-maximize it and then re-maximize, the guest expands with it. A minor thing, but enough to show the old guest additions aren't working as they should with the new vbox.

I found the Linux file on the iso, and ran it as root. It told me I had to remove the old Mageia guest additions before proceeding, which I did with MCC. It said the same when I ran it again, but this time I told it to proceed. It appeared to install with no problems, and I rebooted.

The display symptom noted above disappeared, but an old problem from the early days of Mageia 7 appeared - shared folders weren't being properly mounted. (Bug 24141) The mount points are there, but there's nothing in them, even for root. That's an even bigger mess than the display symptom.

> At most we could try to repackage it, or try to rebuild the 32bit virtualbox
> additions outside the Virtualbox package.

I think we need to do that. While it may be possible for our users to eventually install guest additions from the CD or iso, troubleshooting the result and jumping through hoops to get them to work will be beyond many of them. And it will only get worse the farther away from Vbox 6.0.24 we get.

sorry,
I meant to re-enable the needed 32bit stuff but forgot...

I'll rebuild / upload the missing bits tomorrow

Keywords: (none) => feedback

new set for tests.
- additions are built for i586
- added a buildfix for 5.10 series kernels
- the virtualbox package is an empty package to get upgrade done
  and incompatible host bits removed


SRPMS:
virtualbox-6.1.16-2.mga7.src.rpm
kmod-virtualbox-6.1.16-2.mga7.src.rpm


i586:
virtualbox-6.1.16-2.mga7.i586.rpm
dkms-vboxadditions-6.1.16-2.mga7.noarch.rpm
virtualbox-guest-additions-6.1.16-2.mga7.i586.rpm


x86_64:
dkms-vboxadditions-6.1.16-2.mga7.noarch.rpm
dkms-virtualbox-6.1.16-2.mga7.x86_64.rpm
python-virtualbox-6.1.16-2.mga7.x86_64.rpm
virtualbox-6.1.16-2.mga7.x86_64.rpm
virtualbox-devel-6.1.16-2.mga7.x86_64.rpm
virtualbox-guest-additions-6.1.16-2.mga7.x86_64.rpm

virtualbox-kernel-5.7.19-desktop-3.mga7-6.1.16-2.mga7.x86_64.rpm
virtualbox-kernel-5.7.19-server-3.mga7-6.1.16-2.mga7.x86_64.rpm
virtualbox-kernel-desktop-latest-6.1.16-2.mga7.x86_64.rpm
virtualbox-kernel-server-latest-6.1.16-2.mga7.x86_64.rpm

Keywords: feedback => (none)

After updating the guest additions, my 32-bit guest shows the following message in a little box after boot:

VBoxClient: execve for eturns the following error -1080771044 <NULL>

Bidirectional clipboard now seems to be working correctly, but shared folders are not. I can access the directories with Dolphin, but it cannot read the files.

After removing the shared folders and rebooting, I get the same message, except that the reported error number is 1075015220.

(In reply to Thomas Andrews from comment #24)

> but shared
> folders are not. I can access the directories with Dolphin, but it cannot
> read the files.

This part does not seem to be a new regression with this update. After checking two 32-bit M7 guests, one Plasma and one Xfce, newly created with the netinstall iso, in a Vbox 6.0.24 host, I see the same behavior with regard to files. Directories and files can be manipulated with the various file managers, but applications like Gwenview cannot load and display them.

OK, more information, this time concerning Cauldron 32-bit guests.

I installed a Cauldron Plasma guest from the beta2 iso. After being updated, that one fills the screen, but shared folders don't work, and the vboxsf group doesn't exist. There was no error message like the one in Comment 24.

An examination of the iso file list shows that the guest additions weren't included, so of course they were never installed, and that explains why shared folders don't work. (Guest additions ARE included in the 64-bit isos.) Going back to the 32-bit guest and installing the guest additions creates the vboxsf group, but after adding the user to the group and rebooting, I see the same message as in Comment 24, except possibly with a different number. And, shared folders act the same as they do in M7 32-bit guests if the guest additions are updated to 6.1.16-2.

Removing the guest additions package eliminates the error message, but also eliminates any shared folder operation.

It is not a regression. See bug 26214

Test OK repeated per comment 4 with the virtualbox update and X11 update.

(In reply to Dave Hodgins from comment #28)
> It is not a regression. See bug 26214

Unreadable files in shared folders might not be, but the little box with the error message certainly is.

Sadly this will not fix bug 26214,

Since all rebuild, this seems OK:
(In reply to Morgan Leijström from comment #29)
> Test OK repeated per comment 4 with the virtualbox update and X11 update.

Remark also from this comment #8 in Bug 27323 from David W. Hodgins:

> As root. run "chgrp vboxusers /dev/vbox*", and "chmod g+rw /dev/vbox*".
> 
> Then, using the VMSVGA display driver, started the client with 7.1 x86_64
> installed. After login, restored the dialog box containing the guest display
> using the down arrow near the top right of that dialog, then maximized it.
> The guest resized to match, as normal.
> 
> So it's a permissions problem in the virtualbox rpm. Found it based on
> http://www.mgreene.org/?cat=39 though that fix alone is not enough.

Verified this above step are mandatory to have VMSVGA virtual graphic card to work with Linux. With this, Console mode is OK to have good resolution set by grub.

About the security content, this is a OK.

Whiteboard: (none) => MGA7-64-OK
Keywords: Triaged => advisory, validated_update

Advisory
========================
Updated virtualbox packages fix security vulnerabilities
CVE:
 - CVE-2020-14872
 - CVE-2020-14881
 - CVE-2020-14884
 - CVE-2020-14885
 - CVE-2020-14886
 - CVE-2020-14889
 - CVE-2020-14892
     
  Vulnerabilities in the Oracle VM VirtualBox are fixed in version 6.1.16.
  
  An attacker must first obtain the ability to execute high-privileged code on
  the target guest system in order to exploit this vulnerability which can lead
  to execute code in the context of the hypervisor. (CVE-2020-14872).
  
  An attacker must first obtain the ability to execute high-privileged code on
  the target guest system in order to exploit this vulnerability.
  The specific flaw exists within the shader_generate_main function. The issue
  results from the lack of proper validation of user-supplied data, which can
  result in a read past the end of an allocated buffer. An attacker can
  leverage this in conjunction with other vulnerabilities to execute code in
  the context of the hypervisor. (CVE-2020-14881).
  
  An attacker must first obtain the ability to execute high-privileged code on
  the target guest system in order to exploit this vulnerability.
  The specific flaw exists within the shader_record_register_usage function.
  The issue results from the lack of proper validation of user-supplied data,
  which can result in a type confusion condition. An attacker can leverage
  this in conjunction with other vulnerabilities to execute code in the context
  of the hypervisor. (CVE-2020-14884).
  
  An attacker must first obtain the ability to execute high-privileged code on
  the target guest system in order to exploit this vulnerability. The specific
  flaw exists within the shader_generate_main function. The issue results from
  the lack of proper validation of user-supplied data, which can result in a
  read past the end of an allocated buffer. An attacker can leverage this in
  conjunction with other vulnerabilities to execute code in the context of the
  hypervisor. (CVE-2020-14885).
  
  An attacker must first obtain the ability to execute high-privileged code on
  the target guest system in order to exploit this vulnerability.
  The specific flaw exists within the shader_skip_unrecognized function. The
  issue results from the lack of proper validation of user-supplied data, which
  can result in a read past the end of an allocated buffer. An attacker can
  leverage this in conjunction with other vulnerabilities to execute code in
  the context of the hypervisor. (CVE-2020-14886).
  
  An attacker must first obtain the ability to execute high-privileged code on
  the target guest system in order to exploit this vulnerability which can
  result in unauthorized access to critical data or complete access to all
  Oracle VM VirtualBox accessible data. (CVE-2020-14889).
  
  An attacker must first obtain the ability to execute high-privileged code on
  the target guest system in order to exploit this vulnerability which result
  in unauthorized ability to cause a hang or frequently repeatable crash
  (complete DOS) of Oracle VM VirtualBox. (CVE-2020-14892).

  Also this updated version has some bugfix (See upstream Changelog).

References:
 - https://www.oracle.com/security-alerts/cpuoct2020.html#AppendixOVIR
 - https://www.virtualbox.org/wiki/Changelog-6.1#v16
========================

Updated packages in core/updates_testing:
========================

virtualbox-6.1.16-2.mga7
dkms-vboxadditions-6.1.16-2.mga7
virtualbox-guest-additions-6.1.16-2.mga7
dkms-virtualbox-6.1.16-2.mga7
python-virtualbox-6.1.16-2.mga7
virtualbox-devel-6.1.16-2.mga
virtualbox-kernel-5.7.19-desktop-3.mga7-6.1.16-2.mga7
virtualbox-kernel-5.7.19-server-3.mga7-6.1.16-2.mga7
virtualbox-kernel-desktop-latest-6.1.16-2.mga7
virtualbox-kernel-server-latest-6.1.16-2.mga7

SRPM
- kmod-virtualbox-6.1.16-2.mga7
- virtualbox-6.1.16-2.mga7

CVE: (none) => CVE-2020-14872, CVE-2020-14881, CVE-2020-14884, CVE-2020-14885, CVE-2020-14886, CVE-2020-14889, CVE-2020-14892
Keywords: (none) => advisory

I see 6.1.16-4 in testing.
Is it time to test it now - if so, anything special?
For a new bug?

Updated advisory with updated packages

dkms-vboxadditions-6.1.16-4.mga7
dkms-virtualbox-6.1.16-4.mga7
virtualbox-6.1.16-4.mga7
virtualbox-devel-6.1.16-4.mga7
virtualbox-guest-additions-6.1.16-4.mga7
virtualbox-kernel-5.7.19-desktop-3.mga7-6.1.16-4.mga7
virtualbox-kernel-5.7.19-server-3.mga7-6.1.16-4.mga7
virtualbox-kernel-desktop-latest-6.1.16-4.mga7
virtualbox-kernel-server-latest-6.1.16-4.mga7

from
kmod-virtualbox-6.1.16-4.mga7
virtualbox-6.1.16-4.mga7

Validating
Advisory saved to SVN.

Tested with the packages from Comment 34. No installation issues, in either host or guests.

Windows XP guest, guest additions already installed from previous test, no apparent issues.

64-bit Mageia 7 Plasma guest, no apparent issues. Display size issues with VMSVGA graphics controller apparently now resolved, even though I had not manually applied the fix from Comment 19.

32-bit Mageia 7 Plasma guest, issues brought up in previous comments remain unresolved. 

Even after updating the guest additions package, the small box with the error message appears upon booting. (screenshot to follow) The guest still works, but there are problems. As far as I know, this is a new issue for us with version 6.1.14.

Unlike with 64-bit guests, if VMSVGA is selected as the graphics controller, display size is still limited to but one size, no matter what the window size.

Also, Bug 26214 remains in effect.

Because 64-bit seems to work OK, and because the 32-bit guests do seem to function, if imperfectly, and because this needs to be pushed before we can move on to the new kernels, the problems I'm seeing are probably not quite sufficient to hold this update back any longer. But, once pushed, I will be filing another bug about the 32-bit guest error message.

Created attachment 12128 [details]
Screenshot of the error message after booting a 32-bit Mageia 7 guest

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

https://advisories.mageia.org/MGASA-2020-0466.html

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

This should be added in Advisory:

Note:
- 6.0 branch is EOL upstream since last 2020 summer.
- as of 6.1 series, virtualbox only supports x86_64 hosts: existing 32bits hosts should not upgrade to later version, but this is prone to security vulnerabilities, inconsistencies and un-fixed bugs.