An issue was discovered in Xen through 4.12.x allowing ARM guest OS users to cause a denial of service via a XENMEMaddtophysmap hypercall. p2m->maxmappedgfn is used by the functions p2mresolvetranslationfault() and p2mgetentry() to sanity check guest physical frame. The rest of the code in the two functions will assume that there is a valid root table and check that with BUGON(). The function p2mgetrootpointer() will ignore the unused top bits of a guest physical frame. This means that the function p2msetentry() will alias the frame. However, p2m->maxmappedgfn will be updated using the original frame. It would be possible to set p2m->maxmappedgfn high enough to cover a frame that would lead p2mgetrootpointer() to return NULL in p2mgetentry() and p2mresolvetranslationfault(). Additionally, the sanity check on p2m->maxmappedgfn is off-by-one allowing "highest mapped + 1" to be considered valid. However, p2mgetrootpointer() will return NULL. The problem could be triggered with a specially crafted hypercall XENMEMaddtophysmap{, batch} followed by an access to an address (via hypercall or direct access) that passes the sanity check but cause p2mgetrootpointer() to return NULL. A malicious guest administrator may cause a hypervisor crash, resulting in a Denial of Service (DoS). Xen version 4.8 and newer are vulnerable. Only Arm systems are vulnerable. x86 systems are not affected.