From 75a87af9b228ca7d14902a9390fe5e83c4898eb0 Mon Sep 17 00:00:00 2001 From: David Woodhouse Date: Tue, 25 Jul 2023 12:05:00 +0200 Subject: hw/xen: prevent guest from binding loopback event channel to itself MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Fuzzing showed that a guest could bind an interdomain port to itself, by guessing the next port to be allocated and putting that as the 'remote' port number. By chance, that works because the newly-allocated port has type EVTCHNSTAT_unbound. It shouldn't. Signed-off-by: David Woodhouse Reviewed-by: Paul Durrant Message-Id: <20230801175747.145906-4-dwmw2@infradead.org> Signed-off-by: Philippe Mathieu-Daudé --- hw/i386/kvm/xen_evtchn.c | 11 +++++++++-- 1 file changed, 9 insertions(+), 2 deletions(-) (limited to 'hw') diff --git a/hw/i386/kvm/xen_evtchn.c b/hw/i386/kvm/xen_evtchn.c index 0e9c108..a731738 100644 --- a/hw/i386/kvm/xen_evtchn.c +++ b/hw/i386/kvm/xen_evtchn.c @@ -1408,8 +1408,15 @@ int xen_evtchn_bind_interdomain_op(struct evtchn_bind_interdomain *interdomain) XenEvtchnPort *rp = &s->port_table[interdomain->remote_port]; XenEvtchnPort *lp = &s->port_table[interdomain->local_port]; - if (rp->type == EVTCHNSTAT_unbound && rp->type_val == 0) { - /* It's a match! */ + /* + * The 'remote' port for loopback must be an unbound port allocated for + * communication with the local domain (as indicated by rp->type_val + * being zero, not PORT_INFO_TYPEVAL_REMOTE_QEMU), and must *not* be + * the port that was just allocated for the local end. + */ + if (interdomain->local_port != interdomain->remote_port && + rp->type == EVTCHNSTAT_unbound && rp->type_val == 0) { + rp->type = EVTCHNSTAT_interdomain; rp->type_val = interdomain->local_port; -- cgit v1.1