Description of problem:

On some hardware, when GRUB probes filesystems it may triple fault and reboot the system.

This can be provoked by running "ls -l", or "ls (hd0,msdos2)", or "ls (hd0)", or "search -L garbage", from the GRUB command line (or a GRUB config).

All of these commands result in GRUB probing a partition to determine what it is. In some cases, there is no valid filesystem (or an unsupported one) and therefore GRUB will go through all the filesystems it knows about. The probe for cbfs in at least GRUB 2.02 beta 2 results in a 4 byte memory access to 0xffffffff. This is beyond the end of the segment. On some hardware, this read wraps around to 0x0. On other hardware, this read results in a GP fault (due to enhanced checks). Both of these are valid according to the Intel manual:

    """When the effective limit is FFFFFFFFH (4 GBytes), these accesses may or may not cause the indicated exceptions.
    Behavior is implementation-specific and may vary from one execution to another."""

GRUB was fixed in 2.02 beta 3 to not have this erroneous access:

    commit 855fe6869cc4407569513a231f2a01cb8215e77f
    Author: Vladimir Serbinenko <phcoder>
    Date:   Sun Nov 8 20:34:30 2015 +0100

        cbfs: Check for ptr range sanity.
    
        Triaged by Andrei and enhanced with suggestions by Aaron Durbin
        Also-By: Andrei Borzenkov <arvidjaar>

Please cherry-pick this commit into the grub2 package.


Version-Release number of selected component (if applicable):

All versions of RHEL 7 (I tested up to 7.4 beta).


How reproducible:
Every time.

Steps to Reproduce:
1. At the GRUB menu, press 'c'.
2. Type "ls -l"

Actual results:
A list of disks.

Expected results:
The system crashes and reboots or powers off.

Additional info:
This happens when running RHEL 7 as a VM on recent versions of Xen, but it also happens on some real hardware as well.