Re: [PATCH] virtio-net: validate RSS indirections_len in post_load

["Daniel P. Berrangé" <berrange@redhat.com>]

On Mon, Mar 23, 2026 at 03:25:10PM +0000, Peter Maydell wrote:
> On Mon, 23 Mar 2026 at 14:56, Daniel P. Berrangé <berrange@redhat.com> wrote:
> >
> > On Mon, Mar 23, 2026 at 09:57:24AM -0400, Michael S. Tsirkin wrote:
> > > On Mon, Mar 23, 2026 at 01:53:53PM +0000, Peter Maydell wrote:
> > > > On Mon, 23 Mar 2026 at 13:43, Daniel P. Berrangé <berrange@redhat.com> wrote:
> > > > >
> > > > > On Mon, Mar 23, 2026 at 09:15:31PM +0800, Junjie Cao wrote:
> > > > > > virtio_net_handle_rss() enforces that indirections_len is a non-zero
> > > > > > power of two no larger than VIRTIO_NET_RSS_MAX_TABLE_LEN, but
> > > > > > virtio_net_rss_post_load() applies none of these checks to values
> > > > > > restored from the migration stream.
> > > > > >
> > > > > > A crafted migration stream can set indirections_len to 0.  Even if it
> > > > >
> > > > > The migration stream originating from the source QEMU is trusted.
> > > >
> > > > Is it? In https://www.qemu.org/docs/master/system/security.html we say:
> > > >
> > > > # The following entities are untrusted, meaning that they may be buggy
> > > > # or malicious:
> > > >
> > > > #  * Guest
> > > > #  * User-facing interfaces (e.g. VNC, SPICE, WebSocket)
> > > > #  * Network protocols (e.g. NBD, live migration)
> > > > #  * User-supplied files (e.g. disk images, kernels, device trees)
> > > > #  * Passthrough devices (e.g. PCI, USB)
> > > >
> > > > which explicitly lists "live migration" as an untrusted entity.
> > > >
> > > > I would definitely be extremely cautious about having a threat
> > > > model where I had to distrust inbound migration data, but the
> > > > above does suggest we aim to handle that, and we have I think
> > > > in the past taken patches which add sanity-checking to the
> > > > migration data.
> > >
> > > And we even assigned a low priority CVEs to these.
> >
> > Do you have an example of that ?
> 
> Here's one from last year:
> https://access.redhat.com/security/cve/cve-2025-54566

I think this one is valid, because it involves incorrect handling
of settings that are controlled by the guest OS. There's no
external party claimed to be modifying the migration stream IIUC

> I vaguely recall we had a set of them some years ago too
> (probably somebody specifically looking for flaws in the
> category). https://access.redhat.com/security/cve/cve-2013-4536
> might be an example of that.

I think this one is probably issued in error.

If we're considering that the migration data stream is modifiable
by an attacker, the implication is that the attacker has arbitrary
read and write over the entire of guest RAM. That in turn implies
no guest OS can ever be trusted after a migration has been performed,

That is certainly not the case though.

We establish trust in the guest RAM after migration by protecting
the live migration data stream with TLS (or an equivalent mechanism
external to QEMU), and including some mechanism for authenticating
the connections. We prove the incoming connection is from the
expected source QEMU. That protection also applies to the VMstate
data.

So the only entity would can give us malicious vmstate data would
be the source QEMU.

The risk would appear to be that the source QEMU has been compromised,
but has been unable to break out into the source host OS. The migration
data would thus be leveraged as a way to break out into the target host
OS instead.

This feels dubious though. The source QEMU and target QEMU would be
assumed to be using the same security facilities (running non-root,
using seccomp, using selinux/apparmor, using namespaces, etc). So if
it could not break out of QEMU on the source host, I can't see that
migration would make it possible todo that on the target host either.


The save/restore of VM state to/from disk, for the purpose of VM
snapshotting is slightly different as  we don't have a network
channel involved.

None the less, I'd claim that the saved snapshot file must be considered
trusted, because it again contains data (guest RAM) that we inherently
must trust. If an attacker has the ability to modify a saved state file,
then we've already lost all trust.


I can see scope for CVEs in QEMU wrt vmstate, if:

 * a malicious guest OS driver is able to configure some aspect
   of a virtual device, such that it then causes misbehaviour in
   later handling of the VM state.

   IIUC the recent cve-2025-54566 is an example of that


 * untrusted data being processed by the virtual device, causes
   the device to get itself into a state which then causes
   misbehaviour in handling of VM state. 


I don't accept scope for CVEs in QEMU for an external attacker modifying
the migration data stream or saved state file contents though. AFAICS,
such possibilities imply gross misconfiguration of QEMU by the mgmt app,
and should be CVEs in the mgmt app instead.



With regards,
Daniel
-- 
|: https://berrange.com       ~~        https://hachyderm.io/@berrange :|
|: https://libvirt.org          ~~          https://entangle-photo.org :|
|: https://pixelfed.art/berrange   ~~    https://fstop138.berrange.com :|