intel_microcode: fix heap buffer overflow on -tr loader

When the last microcode region ends at exactly the end of the data file,
intel_ucode_scan_for_microcode() would read data past the end of the
memory buffer.  This is usually harmless.

Unfortunately, should there be a valid microcode exactly after the
memory buffer, iucode_tool will misbehave *badly*.

It is extremely unlikely that the harmful misbehavior could be triggered
by accident -- at least when iucode_tool is linked to glibc -- due to
glibc's memory allocator implementation details.  Also, it is not
believed to be possible for this bug to trigger in a harmful manner when
only one datafile is being processed.

However, it might be possible for an attacker to trigger the issue using
a number of specially crafted data files.  This might also require
tricking the user into using a specially crafted command line.

Should the worst happen, iucode_tool may be convinced to corrupt its
heap, and possibly the libc's heap control data structures.  This could
result in code execution, depending on the libc's internals.

The harmless version of this bug is trivially triggered by using the -tr
(recovery) loader on any file that ends with a valid microcode, such as
any file that only contains valid microcode...

This issue was detected by gcc's address sanitizer.