blob: b47cac84f2e261e9ba129ac32bd251a00236b4b0 (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
|
From: Andrew Cooper <andrew.cooper3@citrix.com>
Subject: x86/mm: Don't perform flush after failing to update a guests L1e
If the L1e update hasn't occured, the flush cannot do anything useful. This
skips the potentially expensive vcpumask_to_pcpumask() conversion, and
broadcast TLB shootdown.
More importantly however, we might be in the error path due to a bad va
parameter from the guest, and this should not propagate into the TLB flushing
logic. The INVPCID instruction for example raises #GP for a non-canonical
address.
This is XSA-279.
Reported-by: Matthew Daley <mattd@bugfuzz.com>
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
index 703f330..75663c6 100644
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -4155,6 +4155,14 @@ static int __do_update_va_mapping(
if ( pl1e )
unmap_domain_page(pl1e);
+ /*
+ * Any error at this point means that we haven't change the L1e. Skip the
+ * flush, as it won't do anything useful. Furthermore, va is guest
+ * controlled and not necesserily audited by this point.
+ */
+ if ( rc )
+ return rc;
+
switch ( flags & UVMF_FLUSHTYPE_MASK )
{
case UVMF_TLB_FLUSH:
|
