CVE-2022-26353 in pve-qemu-kvm 5.2.0-7

[wdoekes]

Hi!

According to git and the apt repository, 5.2.0-7 is the latest pve-qemu-kvm. This contains as fix for CVE-2021-3748. However, that fix introduced a new problem: CVE-2022-26353

https://www.cvedetails.com/cve/CVE-2022-26353/

A flaw was found in the virtio-net device of QEMU. This flaw was inadvertently introduced with the fix for CVE-2021-3748, which forgot to unmap the cached virtqueue elements on error, leading to memory leakage and other unexpected results. Affected QEMU version: 6.2.0.

In git://git.proxmox.com/git/pve-qemu.git, we have:

commit bd07c65bf82b8a04d554937d16c3e09123de4d49 (HEAD -> stable-6, origin/stable-6)
Author: Thomas Lamprecht <t.lamprecht@proxmox.com>
Date:   Wed Mar 30 12:31:02 2022 +0200

    bump version to 5.2.0-7
    
    Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>

commit 31a121e5654a49a3cee0b5af38c0e7b44db276ed
Author: Thomas Lamprecht <t.lamprecht@proxmox.com>
Date:   Wed Mar 30 12:25:39 2022 +0200

    backport various CVE fixes
    
    Was initiated after an user inquired regarding CVE-2021-3748 in the
    forum. To make it worth an update I went through all commits between
    v5.2.0 and current master (~ 7.0.0-rc2) and checked for all messages
    mentioning CVE, but picked only the ones that can actually affect the
    PVE 6.x supported and exposed QEMU features.
    
    Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>

Will you be backporting https://gitlab.com/qemu-project/qemu/-/commit/abe300d9d894f7138e1af7c8e9c88c04bfe98b37 ?

diff --git a/debian/patches/cve-cherry-picks/0013-virtio-net-fix-map-leaking-on-error-during-receive.patch b/debian/patches/cve-cherry-picks/0013-virtio-net-fix-map-leaking-on-error-during-receive.patch
new file mode 100644
index 0000000..dcd3134
--- /dev/null
+++ b/debian/patches/cve-cherry-picks/0013-virtio-net-fix-map-leaking-on-error-during-receive.patch
@@ -0,0 +1,36 @@
+From abe300d9d894f7138e1af7c8e9c88c04bfe98b37 Mon Sep 17 00:00:00 2001
+From: Jason Wang <jasowang@redhat.com>
+Date: Tue, 8 Mar 2022 10:42:51 +0800
+Subject: [PATCH] virtio-net: fix map leaking on error during receive
+
+Commit bedd7e93d0196 ("virtio-net: fix use after unmap/free for sg")
+tries to fix the use after free of the sg by caching the virtqueue
+elements in an array and unmap them at once after receiving the
+packets, But it forgot to unmap the cached elements on error which
+will lead to leaking of mapping and other unexpected results.
+
+Fixing this by detaching the cached elements on error. This addresses
+CVE-2022-26353.
+
+Reported-by: Victor Tom <vv474172261@gmail.com>
+Cc: qemu-stable@nongnu.org
+Fixes: CVE-2022-26353
+Fixes: bedd7e93d0196 ("virtio-net: fix use after unmap/free for sg")
+Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
+Signed-off-by: Jason Wang <jasowang@redhat.com>
+---
+ hw/net/virtio-net.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+Index: pve-qemu-kvm-5.2.0/hw/net/virtio-net.c
+===================================================================
+--- pve-qemu-kvm-5.2.0.orig/hw/net/virtio-net.c
++++ pve-qemu-kvm-5.2.0/hw/net/virtio-net.c
+@@ -1795,6 +1795,7 @@ static ssize_t virtio_net_receive_rcu(Ne
+
+ err:
+     for (j = 0; j < i; j++) {
++        virtqueue_detach_element(q->rx_vq, elems[j], lens[j]);
+         g_free(elems[j]);
+     }
+
diff --git a/debian/patches/series b/debian/patches/series
index 8c2cb1d..be20141 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -10,6 +10,7 @@ cve-cherry-picks/0009-hw-scsi-scsi-disk-MODE_PAGE_ALLS-not-allowed-in-MODE.patch
 cve-cherry-picks/0010-vhost-vsock-detach-the-virqueue-element-in-case-of-e.patch
 cve-cherry-picks/0011-ide-atapi-check-logical-block-address-and-read-size-.patch
 cve-cherry-picks/0012-e1000-fail-early-for-evil-descriptor.patch
+cve-cherry-picks/0013-virtio-net-fix-map-leaking-on-error-during-receive.patch
 extra/0001-Revert-qemu-img-convert-Don-t-pre-zero-images.patch
 extra/0002-docs-don-t-install-man-page-if-guest-agent-is-disabl.patch
 extra/0003-migration-only-check-page-size-match-if-RAM-postcopy.patch

Cheers,
Walter Doekes
OSSO B.V.

 

[t.lamprecht]

According to git and the apt repository, 5.2.0-7 is the latest pve-qemu-kvm.

The latest for the oldstable Proxmox VE 6.4 release based on buster, not the current stable release.

Will you be backporting https://gitlab.com/qemu-project/qemu/-/commit/abe300d9d894f7138e1af7c8e9c88c04bfe98b37 ?

Yes. Note though that this is a relatively (!) harmless memory leak, which can increase memory usage but normally cannot be leveraged in ways as the use after free that got fixed originally, so we don't see this as high pressure.
Also note that Proxmox VE 6.x is going out of support at the end of July (roughly a month).

 

[wdoekes]

Yes. Note though that this is a relatively (!) harmless memory leak, which can increase memory usage but normally cannot be leveraged in ways as the use after free that got fixed originally, so we don't see this as high pressure.

The Ubuntu report https://ubuntu.com/security/notices/USN-5489-1 has this to say:

It was discovered that QEMU incorrectly handled virtio-net devices. A
privileged attacker inside the guest could use this issue to cause QEMU to
crash, resulting in a denial of service, or possibly execute arbitrary
code. (CVE-2022-26353)

The fix does indeed _look_ like it's a memleak only. But I'm not intimate with the code to know how much havoc it could cause. (Eating all memory on the node, causing SIGKILLs, or, worse, actually running exploit code as root.)

Also note that Proxmox VE 6.x is going out of support at the end of July (roughly a month).

pve-qemu-kvm (6.2.0-4) bullseye; urgency=medium

  * d/control: add libgbm to build dependencies

  * d/control: add suggest dependency-hint for libgl1

  * various stable backports:
    + virtio-net: fix map leaking on error during receive
...

Aware of this. Maybe not all nodes will have been upgraded by then
Good to know the fix is in there.

 

[t.lamprecht]

FYI; a package with this fix is now available on the test repository as pve-qemu-kvm version 5.2.0-8

See the following link for how to setup the test repository:
https://pve.proxmox.com/wiki/Package_Repositories#sysadmin_test_repo

 

[wdoekes]

So fast!