Just ahead of the logic in question we've translated the subject MFN to a valid original GFN, in order to then translate that GFN back to an MFN. Restricting the call to p2m_remove_page() to the case where these two MFNs match is too weak. Instead refuse the operation altogether when there's a mismatch (which likely indicates a bug elsewhere in Xen), by leveraging the checking in p2m_remove_entry() via passing in the expected MFN.
Signed-off-by: Jan Beulich <[email protected]> --- If we were certain that a mismatch indicates a bug elsewhere, we might want to consider crashing the domain instead, to limit damage as well as to make sure the issue is actually noticed. --- v2: Drop the check rather than separating it out. --- a/xen/arch/x86/mm/p2m.c +++ b/xen/arch/x86/mm/p2m.c @@ -719,8 +719,7 @@ p2m_add_page(struct domain *d, gfn_t gfn ASSERT(mfn_valid(omfn)); P2M_DEBUG("old gfn=%#lx -> mfn %#lx\n", gfn_x(ogfn) , mfn_x(omfn)); - if ( mfn_eq(omfn, mfn_add(mfn, i)) && - (rc = p2m_remove_entry(p2m, ogfn, omfn, 0)) ) + if ( (rc = p2m_remove_entry(p2m, ogfn, mfn_add(mfn, i), 0)) ) goto out; } }
