This adjusts Debian's grub-mkdevicemap restoration patch to perform safe
allocation.

Signed-off-by: Colin Watson <cjwatson@debian.org>

Patch-Name: deviceiter-overflow.patch

This adjusts Debian's /etc/default/grub.d/*.cfg patch to perform safe
allocation.

Signed-off-by: Colin Watson <cjwatson@debian.org>

Patch-Name: unix-config-overflow.patch

This adjusts Debian's net_bootp6 patch to perform safe allocation.  (In
practice this isn't a security problem because `ln` is 16 bits so it
can't overflow after promotion to 32 bits.)

Signed-off-by: Colin Watson <cjwatson@debian.org>

Patch-Name: bootp-alloc.patch

These could be triggered by a crafted filesystem with very large files.

Fixes: CVE-2020-15707

Signed-off-by: Colin Watson <cjwatson@debian.org>
Reviewed-by: Jan Setje-Eilers <jan.setjeeilers@oracle.com>

Patch-Name: linux-initrd-overflow.patch

Signed-off-by: Peter Jones <pjones@redhat.com>

Patch-Name: linux-loader-overflow.patch

commit 92bfc33d ("efi: Free malloc regions on exit")
introduced memory freeing in grub_efi_fini(), which is
used not only by exit path but by halt/reboot one as well.
As result of memory freeing, code and data regions used by
modules, such as halt, reboot, acpi (used by halt) also got
freed. After return to module code, CPU executes, filled
by UEFI firmware (tested with edk2), 0xAFAFAFAF pattern as
a code. Which leads to #UD exception later.

grub> halt
!!!! X64 Exception Type - 06(#UD - Invalid Opcode)  CPU Apic ID - 00000000 !!!!
RIP  - 0000000003F4EC28, CS  - 0000000000000038, RFLAGS - 0000000000200246
RAX  - 0000000000000000, RCX - 00000000061DA188, RDX - 0A74C0854DC35D41
RBX  - 0000000003E10E08, RSP - 0000000007F0F860, RBP - 0000000000000000
RSI  - 00000000064DB768, RDI - 000000000832C5C3
R8   - 0000000000000002, R9  - 0000000000000000, R10 - 00000000061E2E52
R11  - 0000000000000020, R12 - 0000000003EE5C1F, R13 - 00000000061E0FF4
R14  - 0000000003E10D80, R15 - 00000000061E2F60
DS   - 0000000000000030, ES  - 0000000000000030, FS  - 0000000000000030
GS   - 0000000000000030, SS  - 0000000000000030
CR0  - 0000000080010033, CR2 - 0000000000000000, CR3 - 0000000007C01000
CR4  - 0000000000000668, CR8 - 0000000000000000
DR0  - 0000000000000000, DR1 - 0000000000000000, DR2 - 0000000000000000
DR3  - 0000000000000000, DR6 - 00000000FFFF0FF0, DR7 - 0000000000000400
GDTR - 00000000079EEA98 0000000000000047, LDTR - 0000000000000000
IDTR - 0000000007598018 0000000000000FFF,   TR - 0000000000000000
FXSAVE_STATE - 0000000007F0F4C0

Proposal here is to continue to free allocated memory for
exit boot services path but keep it for halt/reboot path
as it won't be much security concern here.
Introduced GRUB_LOADER_FLAG_EFI_KEEP_ALLOCATED_MEMORY
loader flag to be used by efi halt/reboot path.

Signed-off-by: Alexey Makhalov <amakhalov@vmware.com>
Reviewed-by: Darren Kenny <darren.kenny@oracle.com>

Patch-Name: efi-halt-reboot-use-after-free.patch

The code used in the header was taken from linux kernel commit
f0907827a8a9152aedac2833ed1b674a7b2a44f2.  Rasmus Villemoes
<linux@rasmusvillemoes.dk>, the original author of the patch, was
contacted directly, confirmed his authorship of the code, and gave his
permission on treating that dual license as MIT and including into GRUB2
sources

Signed-off-by: Alex Burmashev <alexander.burmashev@oracle.com>

Patch-Name: safe-alloc-5.patch

This commit introduced a bogus check inside copy_file_path to
determine whether the destination grub_efi_file_path_device_path_t
was valid before anything was copied to it. Depending on the
contents of the heap buffer, this check could fail which would
result in copy_file_path returning early.

Without any error propagated to the caller, make_file_path would
then try to advance the invalid device path node with
GRUB_EFI_NEXT_DEVICE_PATH, which would also fail, returning a NULL
pointer that would subsequently be dereferenced.

Remove the bogus check, and also propagate errors from copy_file_path.

Patch-Name: efi-malformed-device-path-2.patch

Several places we take the length of a device path and subtract 4 from
it, without ever checking that it's >= 4.  There are also cases where
this kind of malformation will result in unpredictable iteration,
including treating the length from one dp node as the type in the next
node.  These are all errors, no matter where the data comes from.

This patch adds a checking macro, GRUB_EFI_DEVICE_PATH_VALID(), which
can be used in several places, and makes GRUB_EFI_NEXT_DEVICE_PATH()
return NULL and GRUB_EFI_END_ENTIRE_DEVICE_PATH() evaluate as true when
the length is too small.  Additionally, it makes several places in the
code check for and return errors in these cases.

Signed-off-by: Peter Jones <pjones@redhat.com>

Patch-Name: efi-malformed-device-path.patch

The grub_free() implementation in kern/mm.c safely handles NULL
pointers, and code at many places depends on this.  We don't know that
the same is true on all host OSes, so we need to handle the same
behavior in grub-emu's implementation.

Signed-off-by: Peter Jones <pjones@redhat.com>
Reviewed-by: Darren Kenny <darren.kenny@oracle.com>

Patch-Name: emu-free-null.patch

It appears to be possible to make a (possibly invalid) lvm PV with a
metadata size field that overflows our type when adding it to the
address we've allocated.  Even if it doesn't, it may be possible to do
so with the math using the outcome of that as an operand.  Check them
both.

Signed-off-by: Peter Jones <pjones@redhat.com>
Signed-off-by: Darren Kenny <darren.kenny@oracle.com>

Patch-Name: lvm-overflow.patch

Both node->size and node->namelen come from the supplied filesystem,
which may be user-supplied.  We can't trust them for the math unless we
know they don't overflow; making sure they go through calloc() first
will give us that.

Signed-off-by: Peter Jones <pjones@redhat.com>
Reviewed-by: Darren Kenny <darren.kenny@oracle.com>

Patch-Name: hfsplus-overflow.patch

Current implementation of grub_relocator_alloc_chunk_align()
does not allow allocation of the top byte.

Assuming input args are:
  max_addr = 0xfffff000;
  size = 0x1000;

And this is valid. But following overflow protection will
unnecessarily move max_addr one byte down (to 0xffffefff):
  if (max_addr > ~size)
    max_addr = ~size;

~size + 1 will fix the situation. In addition, check size
for non zero to do not zero max_addr.

Signed-off-by: Alexey Makhalov <amakhalov@vmware.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>

Patch-Name: relocator-chunk-align-fix-top.patch

Defining a new function with the same name as a previously defined
function causes the grub_script and associated resources for the
previous function to be freed. If the previous function is currently
executing when a function with the same name is defined, this results
in use-after-frees when processing subsequent commands in the original
function.

Instead, reject a new function definition if it has the same name as
a previously defined function, and that function is currently being
executed. Although a behavioural change, this should be backwards
compatible with existing configurations because they can't be
dependent on the current behaviour without being broken.

Fixes: CVE-2020-15706

Signed-off-by: Chris Coulson <chris.coulson@canonical.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>

Patch-Name: script-use-after-free.patch

Signed-off-by: Chris Coulson <chris.coulson@canonical.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>

Patch-Name: script-remove-unused-fields.patch

This commit introduces integer underflow mitigation in max_addr calculation
in grub_relocator_alloc_chunk_align() invocation.

It consists of 2 fixes:
  1. Introduced grub_relocator_alloc_chunk_align_safe() wrapper function to perform
     sanity check for min/max and size values, and to make safe invocation of
     grub_relocator_alloc_chunk_align() with validated max_addr value. Replace all
     invocations such as grub_relocator_alloc_chunk_align(..., min_addr, max_addr - size, size, ...)
     by grub_relocator_alloc_chunk_align_safe(..., min_addr, max_addr, size, ...).
  2. Introduced UP_TO_TOP32(s) macro for the cases where max_addr is 32-bit top
     address (0xffffffff - size + 1) or similar.

Signed-off-by: Alexey Makhalov <amakhalov@vmware.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>

Patch-Name: relocator-chunk-align-underflow.patch

Use arithmetic macros from safemath.h to accomplish it. In this commit,
I didn't want to be too paranoid to check every possible math equation
for overflow/underflow. Only obvious places (with non zero chance of
overflow/underflow) were refactored.

Signed-off-by: Alexey Makhalov <amakhalov@vmware.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>

Patch-Name: relocator-chunk-addr-overflow.patch

There is not need to reassemble the order of blocks. Per RFC 1350,
server must wait for the ACK, before sending next block. Data packets
can be served immediately without putting them to priority queue.

Logic to handle incoming packet is this:
  - if packet block id equal to expected block id, then
    process the packet,
  - if packet block id is less than expected - this is retransmit
    of old packet, then ACK it and drop the packet,
  - if packet block id is more than expected - that shouldn't
    happen, just drop the packet.

It makes the tftp receive path code simpler, smaller and faster.
As a benefit, this change fixes CID# 73624 and CID# 96690, caused
by following while loop:

  while (cmp_block (grub_be_to_cpu16 (tftph->u.data.block), data->block + 1) == 0)

where tftph pointer is not moving from one iteration to another, causing
to serve same packet again. Luckily, double serving didn't happen due to
data->block++ during the first iteration.

Fixes: CID 73624, CID 96690

Signed-off-by: Alexey Makhalov <amakhalov@vmware.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>

Patch-Name: tftp-no-priority-queue.patch

Fixes: CID 292468

Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>

Patch-Name: multiboot2-leak.patch

Fixes: CID 73796

Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Reviewed-by: Jan Setje-Eilers <jan.setjeeilers@oracle.com>

Patch-Name: udf-leak.patch

This requires a very weird input from the serial interface but can cause
an overflow in input_buf (keys) overwriting the next variable (npending)
with the user choice:

(pahole output)

struct grub_terminfo_input_state {
        int                        input_buf[6];         /*     0    24 */
        int                        npending;             /*    24     4 */ <- CORRUPT
        ...snip...

The magic string requires causing this is "ESC,O,],0,1,2,q" and we overflow
npending with "q" (aka increase npending to 161). The simplest fix is to
just to disallow overwrites input_buf, which exactly what this patch does.

Fixes: CID 292449

Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>

Patch-Name: term-overflow.patch

The two dimensional array p->posSlotEncoder[4][64] is being dereferenced
using the GetLenToPosState() macro which checks if len is less than 5,
and if so subtracts 2 from it. If len = 0, that is 0 - 2 = 4294967294.
Obviously we don't want to dereference that far out so we check if the
position found is greater or equal kNumLenToPosStates (4) and bail out.

N.B.: Upstream LZMA 18.05 and later has this function completely rewritten
without any history.

Fixes: CID 51526

Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>

Patch-Name: lzma-overflow.patch

grub_xnu_devprop_add_property() should not free utf8 and utf16 as it get
allocated and freed in the caller.

Minor improvement: do prop fields initialization after memory allocations.

Fixes: CID 292442, CID 292457, CID 292460, CID 292466

Signed-off-by: Alexey Makhalov <amakhalov@vmware.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>

Patch-Name: xnu-double-free.patch

self->bitmap should be zeroed after free. Otherwise, there is a chance
to double free (USE_AFTER_FREE) it later in rescale_image().

Fixes: CID 292472

Signed-off-by: Alexey Makhalov <amakhalov@vmware.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>

Patch-Name: gfxmenu-load-image-double-free.patch

The GRUB font file can have one NAME section only. Though if somebody
crafts a broken font file with many NAME sections and loads it then the
GRUB leaks memory. So, prevent against that by loading first NAME
section and failing in controlled way on following one.

Reported-by: Chris Coulson <chris.coulson@canonical.com>
Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
Reviewed-by: Jan Setje-Eilers <jan.setjeeilers@oracle.com>

Patch-Name: font-name-leak.patch

Signed-off-by: Peter Jones <pjones@redhat.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>

Patch-Name: iso9660-realloc-leak.patch

This attempts to fix the places where we do the following where
arithmetic_expr may include unvalidated data:

  X = grub_malloc(arithmetic_expr);

It accomplishes this by doing the arithmetic ahead of time using grub_add(),
grub_sub(), grub_mul() and testing for overflow before proceeding.

Among other issues, this fixes:
  - allocation of integer overflow in grub_video_bitmap_create()
    reported by Chris Coulson,
  - allocation of integer overflow in grub_png_decode_image_header()
    reported by Chris Coulson,
  - allocation of integer overflow in grub_squash_read_symlink()
    reported by Chris Coulson,
  - allocation of integer overflow in grub_ext2_read_symlink()
    reported by Chris Coulson,
  - allocation of integer overflow in read_section_as_string()
    reported by Chris Coulson.

Fixes: CVE-2020-14309, CVE-2020-14310, CVE-2020-14311

Signed-off-by: Peter Jones <pjones@redhat.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>

Patch-Name: safe-alloc-4.patch

This modifies most of the places we do some form of:

  X = malloc(Y * Z);

to use calloc(Y, Z) instead.

Among other issues, this fixes:
  - allocation of integer overflow in grub_png_decode_image_header()
    reported by Chris Coulson,
  - allocation of integer overflow in luks_recover_key()
    reported by Chris Coulson,
  - allocation of integer overflow in grub_lvm_detect()
    reported by Chris Coulson.

Fixes: CVE-2020-14308

Signed-off-by: Peter Jones <pjones@redhat.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>

Patch-Name: safe-alloc-3.patch

This tries to make sure that everywhere in this source tree, we always have
an appropriate version of calloc() (i.e. grub_calloc(), xcalloc(), etc.)
available, and that they all safely check for overflow and return NULL when
it would occur.

Signed-off-by: Peter Jones <pjones@redhat.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>

Patch-Name: safe-alloc-2.patch