Bug 28530 - [Update candidate] xen packages fix new security issues (CVE-2021-26933 and CVE-2021-26934)
Summary: [Update candidate] xen packages fix new security issues (CVE-2021-26933 and C...
Status: NEW
Alias: None
Product: Mageia
Classification: Unclassified
Component: Security (show other bugs)
Version: 8
Hardware: All Linux
Priority: Normal normal
Target Milestone: ---
Assignee: Thierry Vignaud
QA Contact: Sec team
Keywords: NEEDINFO, feedback
Depends on:
Reported: 2021-03-05 16:23 CET by Thierry Vignaud
Modified: 2022-05-18 03:55 CEST (History)
4 users (show)

See Also:
Source RPM: xen-4.16.0-1.mga8
CVE: CVE-2021-26933, CVE-2021-26934
Status comment:


Description Thierry Vignaud 2021-03-05 16:23:05 CET
Build: http://pkgsubmit.mageia.org/uploads/done/8/core/updates_testing/20210305081520.tv.duvel.8597/

This update of xen add support for zstd dom0 & guest as well as fixes several security issues:
 - Linux: display frontend "be-alloc" mode is unsupported (comment only)
        [XSA-363, CVE-2021-26934] (rhbz#1929549)
- arm: The cache may not be cleaned for newly allocated scrubbed pages
        [XSA-364, CVE-2021-26933] (rhbz#1929547)
- backport upstream zstd dom0 and guest patches
- add weak dependency on grub modules to improve initial boot setup
- IRQ vector leak on x86 [XSA-360]

List of packages:


(similar for armv7/aarch64)
Nicolas Lécureuil 2021-03-07 20:11:22 CET

CC: (none) => mageia
QA Contact: (none) => security

David Walser 2021-03-07 22:07:13 CET

Component: RPM Packages => Security

Comment 1 Dave Hodgins 2021-04-03 09:55:38 CEST
http://mirror.math.princeton.edu/pub/mageia/distrib/8/x86_64/media/core/release/has xen-4.14.1-1.mga8.x86_64.rpm
has xen-4.14.1-1.mga8.x86_64.rpm

Looks like release bump was missed.

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

Comment 2 Dave Hodgins 2021-04-03 15:33:35 CEST
Couldn't get the release version working with refind, so tried with grub2.

While it's no longer necessary to manually add a grub entry, I didn't figure
out how to change just the xen command line parameters, so just changed it
for all boots so in xen, /proc/cmdline has ...
placeholder root=UUID=1f3bf0c9-719c-4c75-b8e5-f03203154de0 ro noiswmd modprobedebug audit=0 nouveau.modeset=0 resume=LABEL=e1swap dom0_mem=4096MB vga=794

Xorg is failing to start with ...
[    25.736] (II) UnloadModule: "fbdev"
[    25.736] (II) Unloading fbdev
[    25.736] (II) UnloadSubModule: "fbdevhw"
[    25.736] (II) Unloading fbdevhw
[    25.736] (II) UnloadModule: "vesa"
[    25.736] (II) Unloading vesa
[    25.737] (II) NVIDIA: Using 24576.00 MB of virtual memory for indirect memory
[    25.737] (II) NVIDIA:     access.
[    25.743] (EE) NVIDIA(0): Failed to allocate shared surface
[    25.788] (EE) 
Fatal server error:
[    25.788] (EE) AddScreen/ScreenInit failed for driver 0

On a normal Mageia boot, the corresponding section has ...
[    16.769] (II) NVIDIA: Using 24576.00 MB of virtual memory for indirect memory
[    16.769] (II) NVIDIA:     access.
[    16.815] (II) NVIDIA(0): Setting mode "NULL"
[    16.829] (==) NVIDIA(0): Disabling shared memory pixmaps

The system has 16GB Ram, 32GB swap.

For xorg, I'm using mageia-prime with
# lspcidrake -v|grep Card
Card:ATI Volcanic Islands and later (amdgpu): Advanced Micro Devices, Inc. [AMD/ATI]|Renoir [DISPLAY_VGA] (vendor:1002 device:1636 subv:1043 subd:1e21) (rev: c6)
Card:NVIDIA GeForce 635 series and later: NVIDIA Corporation|TU106M [GeForce RTX 2060 Mobile] [DISPLAY_VGA] (vendor:10de device:1f15 subv:1043 subd:1e21) (rev: a1)

When the update with the bumped release is available, I'll just be checking
that the updates install cleanly over the current version, unless someone
can figure out what's needed to get this running.
Comment 3 Dave Hodgins 2021-04-03 16:06:48 CEST
The existing xen also has an boot delaying bug with ...
Xen boot entries ask for nonexistent grub2 module2.mod

has a fix for that one.

This is with the release version packages isntalled for ...
Comment 4 Aurelien Oudelet 2021-07-13 10:48:59 CEST
Ping ? 101 days since last action here.

Summary: [Update candidate] xen => [Update candidate] xen packages fix new security issues (CVE-2021-26933
CC: (none) => ouaurelien
CVE: (none) => CVE-2021-26933, CVE-2021-26934

Aurelien Oudelet 2021-07-13 10:49:13 CEST

Summary: [Update candidate] xen packages fix new security issues (CVE-2021-26933 => [Update candidate] xen packages fix new security issues (CVE-2021-26933 and CVE-2021-26934)

Comment 5 Dave Hodgins 2021-11-04 17:21:06 CET
Reassigning back to packager

Assignee: qa-bugs => thierry.vignaud

Comment 6 Nicolas Lécureuil 2021-12-14 00:03:44 CET
Thierry, can you take a look to this bugreport ?
Comment 7 Thierry Vignaud 2022-01-11 14:48:57 CET
Dave, can you check xen-4.16 in cauldron?
If it works smoothly, I can backport it into mga8

Keywords: (none) => NEEDINFO

Comment 8 Dave Hodgins 2022-01-13 00:08:33 CET
I installed Mageia 9 on my uefi laptop from comment 2 and got it working, then
installed xen.

Booting Mageia with xen hypervisor, xorg is still failing with
(EE) NVIDIA(0): Failed to allocate shared surface

Networking is also not currently working within xen.

Haven't done any configuration or created an guests yet, just installed and
rebooted using grub2-efi.
Comment 9 Dave Hodgins 2022-01-13 03:23:20 CET
I decided to try running mageia-prime-uninstall and then try booting Mageia
Cauldron with Xen. It's working for getting to xorg display, so the problem is
specific to xen with nvidia, or perhaps xen with mageia-prime using nvidia.

I noticed that when running ifup, there is now a warning that it's deprecated.
Does networkmanager now support bridging? If not, deprecating the network
scripts will stop being able to get networking working under xen.

I'll try setting up the networking and a guest tomorrow.
Comment 10 Dave Hodgins 2022-01-16 21:58:40 CET
I went back to testing the m8 version, on my main system where I'd had xen
working in the past (long past).

As ifup is going to be deprecated, and everything I've read indicates xen
does not work with networkmanager, I used systemd to create the bridge as per

That works. I have the hypervisor running now, the network is up, and is
working for both ipv4 and ipv6 traffic.

I'm having problems with the first domu test. In the past, in bug 16956, I was
only able to get a hvm guest working on this computer, so that's what I'm
# cat x8xenhvm.cfg 
disk = [ 'file:/opt/hvmtest.img,sda,w', 'file:/s3/m8/Mageia-8-Live-Xfce-x86_64/Mageia-8-Live-Xfce-x86_64.iso,hdb:cdrom,r', ]
vif = [ 'type=ioemu, mac=00:1f:5a:71:ae:37, bridge=xenbr', ] # choose a random mac

However when I run "xl create x8xenhvm", it causes the host system to hard boot
as if the reset button had been pressed.

Between that, and the nvidia problem which affects both m8 and cauldron
versions, not sure how to go any further.
Comment 11 Thierry Vignaud 2022-01-17 20:57:03 CET
OK, I've updated xen to 4.16.0-1.mga8 in core/updates_testing

Source RPM: xen-4.14.1-1.mga8 => xen-4.16.0-1.mga8

Comment 12 Dave Hodgins 2022-01-17 23:09:39 CET
First boot locked up early in boot during display of physical ram map. Magic
sysrq keys non-responsive. Used the reset button.

Second boot, was able to login (I use run level 3, then startx on this system).
Locked up again while starting kde, requiring reset again. Repeated on third
boot, locking up in the same place during kde start.

Fourth boot. Used "startx startxfce4". Was able to get to the xfce4 desktop.
In a terminal ...
# xl create /etc/xen/x8xenhvm.cfg 
Parsing config from /etc/xen/x8xenhvm.cfg
WARNING: ignoring "vncviewer" option. Use "-V" option of "xl create" to automatically spawn vncviewer.
libxl: info: libxl_create.c:121:libxl__domain_build_info_setdefault: qemu-xen is unavailable, using qemu-xen-traditional instead: No such file or directory
libxl: error: libxl_dm.c:2882:libxl__spawn_local_dm: Domain 1:device model /usr/libexec/xen/bin/qemu-dm is not executable: No such file or directory
libxl: error: libxl_dm.c:3131:device_model_spawn_outcome: Domain 1:(null): spawn failed (rc=-3)
libxl: error: libxl_dm.c:3351:device_model_postconfig_done: Domain 1:Post DM startup configs failed, rc=-3
libxl: error: libxl_create.c:1867:domcreate_devmodel_started: Domain 1:device model did not start: -3
libxl: error: libxl_domain.c:1183:libxl__destroy_domid: Domain 1:Non-existant domain
libxl: error: libxl_domain.c:1137:domain_destroy_callback: Domain 1:Unable to destroy guest
libxl: error: libxl_domain.c:1064:domain_destroy_cb: Domain 1:Destruction of domain failed

So the xl create is no longer causing a hard boot, but problems remain.

Note that during install, qemu-system-x86-core-0:5.2.0-4.mga8 had to be
removed due to conflicts.
Comment 13 Giuseppe Ghibò 2022-04-23 19:57:40 CEST
(In reply to Dave Hodgins from comment #12)

> Note that during install, qemu-system-x86-core-0:5.2.0-4.mga8 had to be
> removed due to conflicts.

I uploaded a new build of qemu in updates_testing (it fixes a few bugs about rebuilding as well as some CVE) rebuilt against the xen version in same updates_testing, so it should no longer be removed for conflicts.

CC: (none) => ghibomgx

Comment 14 Dave Hodgins 2022-04-23 20:38:51 CEST
(In reply to Giuseppe Ghibò from comment #13)
> (In reply to Dave Hodgins from comment #12)
> > 
> > Note that during install, qemu-system-x86-core-0:5.2.0-4.mga8 had to be
> > removed due to conflicts.
> I uploaded a new build of qemu in updates_testing (it fixes a few bugs about
> rebuilding as well as some CVE) rebuilt against the xen version in same
> updates_testing, so it should no longer be removed for conflicts.

From a test install with --debug ...
chosen lib64xen3.0-4.14.1-1.mga8.x86_64 for libxenctrl.so.4.14()(64bit)
the more recent lib64xen3.0-4.16.0-1.mga8.x86_64 is installed, but does not provide libxenctrl.so.4.14()(64bit) whereas lib64xen3.0-4.14.1-1.mga8.x86_64 does

After that ...
To satisfy dependencies, the following packages are going to be installed:
  Package                        Version      Release       Arch    
(medium "Core Release (distrib1)")
  lib64daxctl1                   68           2.mga8        x86_64  
  lib64fdt1                      1.5.1        3.mga8        x86_64  
  lib64mpathcmd0                 0.8.5        2.mga8        x86_64  
  lib64mpathpersist0             0.8.5        2.mga8        x86_64  
  lib64multipath0                0.8.5        2.mga8        x86_64  
  lib64virglrenderer1            0.8.2        1.20200212gi> x86_64  
  qemu-common                    5.2.0        4.mga8        x86_64  
  seabios-bin                    1.14.0       1.mga8        noarch

Should I downgrade xen first and then test again?
Comment 15 Giuseppe Ghibò 2022-04-23 20:44:46 CEST
No, get xen from updates_testing too. The right qemu version is 5.2.0-4.1.mga8, it has just built, wait a couple of minutes as it propagates to mirrors.
Comment 16 Dave Hodgins 2022-04-23 23:04:12 CEST

xl create /etc/xen/x8xenhvm.cfg  -c -d -V
with the config file from comment 8 is now working, and I can access the
network from a live iso running in the guest (once I configure the dns servers).
Sound isn't working, but that's a config issue I'll sort out another time.

So qemu and xen are ready to validate, but virt-manager cannot be installed due
to ...
the more recent lib64xen3.0-4.16.0-1.mga8.x86_64 is installed, but does not provide libxenstore.so.3.0()(64bit) whereas lib64xen3.0-4.14.1-1.mga8.x86_64 does

So virt-manager will need a rebuild or update too.
Comment 17 Dave Hodgins 2022-04-23 23:07:11 CEST
gnome-boxes will need a rebuild or update too.
Comment 18 Giuseppe Ghibò 2022-04-23 23:38:07 CEST
BTW, I noticed that xen in cauldron has more CVE updates (and also a newer release 4.16.1). E.g.: https://svnweb.mageia.org/packages/cauldron/xen/current/SPECS/xen.spec?revision=1770708&view=markup, https://svnweb.mageia.org/packages/cauldron/xen/current/SPECS/xen.spec?r1=1817555&r2=1846236 or 4.16.1 that includes them all.

Maybe worthwhile to use that patches too and rebuild xen too?
Comment 19 Dave Hodgins 2022-04-24 03:46:28 CEST
If the current version is still supported, I don't see a justification for
updating to a newer release. As this is a security update, it would be better
to get gnome-boxes and virt-manager fixed, and this update pushed.
Comment 20 Giuseppe Ghibò 2022-04-24 10:14:01 CEST
(In reply to Dave Hodgins from comment #19)

> If the current version is still supported, I don't see a justification for
> updating to a newer release. As this is a security update, it would be better
> to get gnome-boxes and virt-manager fixed, and this update pushed.

Ok, I only cited, because the cauldron xen version (either 4.16.1 or 4.16.0+patches) has fixes also for CVE-2022-23033, CVE-2022-23034, CVE-2022-23035, XSA-398, CVE-2022-26357, CVE-2022-26358, CVE-2022-26359, CVE-2022-26360, CVE-2022-26361 that current xen version in mga8/updates_testing hasn't yet. Anyway we can proceed in two steps, completing the missed rebuilding first and then releasing another xen in a 2nd step in another bug.
Comment 21 Dave Hodgins 2022-04-24 17:46:13 CEST
Additional cve entries is justification for a new update.
looks like it's mostly bug fixes.

I'll leave it to you whether to add more patches to 4.16.0 or go with 4.16.1
Comment 22 Giuseppe Ghibò 2022-04-25 16:58:19 CEST
OK, since with the patches or the 4.16.1 tarball was the exactly same, I uploaded xen-4.16.1-1.2.mga8 in mga8's updates_testing (I included also couple of fixes for python3 scripts, otherwise for instance the script "xencons" won't run). Such fixes needs also to be included in cauldron. Have to remind.

I rebuilt also libvirt and qemu again against this latest 4.16.1-1.2. 

As for gnome-boxes does it still needs to be rebuilt? Currently old gnome-boxes-3.38.2-2.mga8 seems downloading/installing without broken deps. Actually gnome-boxes has these buildrequires:


which are provided by libvirt-glib. Does libvirt-glib to be rebuilt too?
Comment 23 Dave Hodgins 2022-04-30 23:46:05 CEST
gnome-boxes fails, though it's not clear why ...
$ grep libvirt gnome-boxes.log 
2020-10-06 01:33:11.796+0000: starting up libvirt version: 5.5.0, qemu version: 4.0.0qemu-4.0.0-2.mga7, kernel: 5.7.19-desktop-1.mga7, hostname: x3.hodgins.homeip.net
XDG_CACHE_HOME=/home/dave/.config/libvirt/qemu/lib/domain-1-boxes-unknown/.cache \
-object secret,id=masterKey0,format=raw,file=/home/dave/.config/libvirt/qemu/lib/domain-1-boxes-unknown/master-key.aes \
2020-10-06 01:38:45.158+0000: starting up libvirt version: 5.5.0, qemu version: 4.0.0qemu-4.0.0-2.mga7, kernel: 5.7.19-desktop-1.mga7, hostname: x3.hodgins.homeip.net
XDG_CACHE_HOME=/home/dave/.config/libvirt/qemu/lib/domain-2-boxes-unknown/.cache \
-object secret,id=masterKey0,format=raw,file=/home/dave/.config/libvirt/qemu/lib/domain-2-boxes-unknown/master-key.aes \
2020-10-06T01:42:21.197511Z qemu-system-x86_64: terminating on signal 15 from pid 30158 (/usr/sbin/libvirtd)

$ rpm -q gnome-boxes xen qemu
Comment 24 Giuseppe Ghibò 2022-05-06 17:58:23 CEST
There is a new rebuilt of gnome-boxes-3.38.2-2.1.mga8 as well as libvirt-glib-3.0.0-2.1.mga8; you might try with them too.
Comment 25 Giuseppe Ghibò 2022-05-16 18:40:17 CEST
Does it work with gnome-boxes-3.38.2-2.1.mga8 ?
Comment 26 Dave Hodgins 2022-05-16 21:21:12 CEST
I tried gnome-boxes while booted under the xen hypervisor, which doesn't work.

Booting normally with the Mageia kernel, it fails to start a virtual machine
I created the last time I tested gnome boxes successfully.

Just now, I tried creating a new virtual machine (using Mageia kernel) and
it's working, so there's something it didn't like about my old machine.

Ready to kick myself. :-) Just realized the old machine was set to use
the Mageia 8 beta1 iso image, which no longer exists on my system. Wish the
messages generated when it fails made it clear instead of a hundred plus
lines in the trouble shooting log, with no clear indication it was file
not found.

I'll review the update and hopefully validate everything later today.

Have to go out for a while right now.
Comment 27 Giuseppe Ghibò 2022-05-17 00:53:10 CEST
BTW are i586 or x86_64 the vms? As on just qemu with i586 (with latest kernel beyond 5.10.18), I get a behaviour opposite to yours with mga8, i.e. it won't boot. Backing back to 5.10.18 it boots. This happens also on any qemu version (not just the ones related to this update), including qemu 7 from cauldron.
I also noticed the timestamp saying "terminating on signal 15" from the log at comment #23 are from 2020. Were that ok?
Comment 28 Dave Hodgins 2022-05-18 03:31:17 CEST
Ignore comment #23. I was trying to run gnome-boxes while the host was running
under the hypervisor.

Current status. Running xen with Mageia-8-Live-Xfce-x86_64.iso works running
the iso in live mode. After installing that to the virtual hard disk, booting
into Mageia from the virtual hard disk stops with the last message displayed
being about the random number generator being initialized.

Running xen with Mageia-8-Live-Xfce-i586.iso works in live mode, but trying
to install to the virtual hard disk, the virtual machine terminates while
formatting the file system, with no messages.

I'll boot back to the regular Mageia kernel, and try gnome-boxes again.
Comment 29 Dave Hodgins 2022-05-18 03:55:36 CEST
With gnome boxes, I can run either iso in live mode, but I see no way to add
a virtual hard drive or connect it to the network. It boots and runs the live
iso with the delay while trying to start networking. With no network or hard
drive, it's very limited.

Note You need to log in before you can comment on or make changes to this bug.