The usage of atomic_dec_and_test() in msixtbl_pt_unregister() is inverted:
the function will return true when the refcount reaches 0. The current
code does the opposite and calls del_msixtbl_entry() when there are still
refcounts held on the object.
However all callers of msixtbl_pt_unregister() are serialized on the domctl
lock, and hence there cannot be parallel calls to msixtbl_pt_unregister()
that could lead to double freeing of the same object.
The incorrect freeing with active msixtlb entries will result in a possible
guest visible malfunction, but no internal Xen state corruption.
While entries are leaked once the last pIRQ is unbound, the same entry
would get re-used if the device has pIRQs bound again. The guest cannot
exploit this incorrect refcount check to leak arbitrary amounts of memory
by repeatedly enabling and disabling (binding and unbinding) MSI-X entries.
Fixes: 34097f0d3080 ('hvm: passthrough MSI-X mask bit acceleration')
Signed-off-by: Roger Pau Monné <[email protected]>
Reviewed-by: Jan Beulich <[email protected]>
---
xen/arch/x86/hvm/vmsi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/xen/arch/x86/hvm/vmsi.c b/xen/arch/x86/hvm/vmsi.c
index 32e417bc1592..27b1f089e20b 100644
--- a/xen/arch/x86/hvm/vmsi.c
+++ b/xen/arch/x86/hvm/vmsi.c
@@ -716,7 +716,7 @@ out:
return;
found:
- if ( !atomic_dec_and_test(&entry->refcnt) )
+ if ( atomic_dec_and_test(&entry->refcnt) )
del_msixtbl_entry(entry);
spin_unlock_irq(&irqd->lock);
--
2.51.0
