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
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
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
This adds a new header, include/grub/safemath.h, that includes easy to
use wrappers for __builtin_{add,sub,mul}_overflow() declared like:
bool OP(a, b, res)
where OP is grub_add, grub_sub or grub_mul. OP() returns true in the
case where the operation would overflow and res is not modified.
Otherwise, false is returned and the operation is executed.
These arithmetic primitives require newer compiler versions. So, bump
these requirements in the INSTALL file too.
Signed-off-by: Peter Jones <pjones@redhat.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Patch-Name: safe-alloc-1.patch
When presented with a command that can't be tokenized to anything
smaller than YYLMAX characters, the parser calls YY_FATAL_ERROR(errmsg),
expecting that will stop further processing, as such:
#define YY_DO_BEFORE_ACTION \
yyg->yytext_ptr = yy_bp; \
yyleng = (int) (yy_cp - yy_bp); \
yyg->yy_hold_char = *yy_cp; \
*yy_cp = '\0'; \
if ( yyleng >= YYLMAX ) \
YY_FATAL_ERROR( "token too large, exceeds YYLMAX" ); \
yy_flex_strncpy( yytext, yyg->yytext_ptr, yyleng + 1 , yyscanner); \
yyg->yy_c_buf_p = yy_cp;
The code flex generates expects that YY_FATAL_ERROR() will either return
for it or do some form of longjmp(), or handle the error in some way at
least, and so the strncpy() call isn't in an "else" clause, and thus if
YY_FATAL_ERROR() is *not* actually fatal, it does the call with the
questionable limit, and predictable results ensue.
Unfortunately, our implementation of YY_FATAL_ERROR() is:
#define YY_FATAL_ERROR(msg) \
do { \
grub_printf (_("fatal error: %s\n"), _(msg)); \
} while (0)
The same pattern exists in yyless(), and similar problems exist in users
of YY_INPUT(), several places in the main parsing loop,
yy_get_next_buffer(), yy_load_buffer_state(), yyensure_buffer_stack,
yy_scan_buffer(), etc.
All of these callers expect YY_FATAL_ERROR() to actually be fatal, and
the things they do if it returns after calling it are wildly unsafe.
Fixes: CVE-2020-10713
Signed-off-by: Peter Jones <pjones@redhat.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Patch-Name: CVE-2020-10713.patch
For complicated reasons, even if you have XSM/FLASK disabled (as is
the default) the Xen build system still builds a policy file and puts
it in /boot.
Even so, we shouldn't be loading this in the usual non-"XSM enabled"
entries. It doesn't do any particular harm but it is quite confusing.
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Bug-Debian: https://bugs.debian.org/961673
Last-Update: 2020-05-29
Patch-Name: xen-no-xsm-policy-in-non-xsm-options.patch
XSM is enabled by adding "flask=enforcing" as a Xen command line
argument, and providing the policy file as a grub module.
We make entries for both with and without XSM. If XSM is not compiled
into Xen, then there are no policy files, so no change to the boot
options.
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Origin: upstream, https://git.savannah.gnu.org/cgit/grub.git/commit/?id=a81401ff493958e626e84f802f44434978fa4d4d
Last-Update: 2020-05-27
Patch-Name: xen-support-xsm.patch
file_is_not_sym() currently only checks for xen-syms. Extend it to
disregard xenpolicy (XSM policy files) and files ending .config (which
are built by the Xen upstream build system in some configurations and
can therefore end up in /boot).
Rename the function accordingly, to file_is_not_xen_garbage().
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Origin: upstream, https://git.savannah.gnu.org/cgit/grub.git/commit/?id=7a9b30143bb9f6fc19b4e1cf8d4d184a49c3c36e
Last-Update: 2020-05-27
Patch-Name: xen-ignore-xenpolicy-and-config.patch
When booting on an ARMv8 core that implements either CTR.IDC or CTR.DIC
(indicating that some of the cache maintenance operations can be
removed when dealing with I/D-cache coherency, GRUB dies with a
"Unsupported cache type 0x........" message.
This is pretty likely to happen when running in a virtual machine
hosted on an arm64 machine (I've triggered it on a system built around
a bunch of Cortex-A55 cores, which implements CTR.IDC).
It turns out that the way GRUB deals with the CTR register is a bit
harsh for anything from ARMv7 onwards. The layout of the register is
backward compatible, meaning that nothing that gets added is allowed to
break earlier behaviour. In this case, ignoring IDC is completely fine,
and only results in unnecessary cache maintenance.
We can thus avoid being paranoid, and align the 32bit behaviour with
its 64bit equivalent.
This patch has the added benefit that it gets rid of a (gnu-specific)
case range too.
Signed-off-by: Marc Zyngier <maz@kernel.org>
Reviewed-by: Leif Lindholm <leif@nuviainc.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
XSM is enabled by adding "flask=enforcing" as a Xen command line
argument, and providing the policy file as a grub module.
We make entries for both with and without XSM. If XSM is not compiled
into Xen, then there are no policy files, so no change to the boot
options.
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
file_is_not_sym() currently only checks for xen-syms. Extend it to
disregard xenpolicy (XSM policy files) and files ending .config (which
are built by the Xen upstream build system in some configurations and
can therefore end up in /boot).
Rename the function accordingly, to file_is_not_xen_garbage().
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Nested functions are not supported in C, but are permitted as an extension
in the GNU C dialect. Commit cb2f15c544 ("normal/main: Search for specific
config files for netboot") added a nested function which caused the build
to break when compiling with clang.
Break that out into a static helper function to make the code portable again.
Reported-by: Daniel Axtens <dja@axtens.net>
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
Tested-by: Daniel Axtens <dja@axtens.net>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The module is only enabled for x86_64, but there's nothing specific to
x86_64 in the implementation and can be enabled for all EFI platforms.
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
..to reflect the GRUB build reality in them.
Additionally, fix text formatting a bit.
Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
Reviewed-by: Leif Lindholm <leif@nuviainc.com>
Commit d5a32255d (misc: Make grub_strtol() "end" pointers have safer
const qualifiers) introduced "restrict" keyword into some functions
definitions. This keyword was introduced in C99 standard. However, some
compilers by default may use C89 or something different. This behavior
leads to the breakage during builds when c89 or gnu89 is in force. So,
let's set gnu99 C language standard for all compilers by default. This
way a bit random build issue will be fixed and the GRUB source will be
build consistently regardless of type and version of the compiler.
It was decided to use gnu99 C language standard because it fixes the
issue mentioned above and also provides some useful extensions which are
used here and there in the GRUB source. Potentially we can use gnu11
too. However, this may reduce pool of older compilers which can be used
to build the GRUB. So, let's live with gnu99 until we discover that we
strongly require a feature from newer C standard.
The user is still able to override C language standard using relevant
*_CFLAGS variables.
Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
Reviewed-by: Leif Lindholm <leif@nuviainc.com>
grub_tpm_log_event() and grub_tpm_measure() are two functions that
have the same effect. So, keep grub_tpm_log_event() and rename it
to grub_tpm_measure(). This way we get also a more clear semantics.
Signed-off-by: Tianjia Zhang <tianjia.zhang@linux.alibaba.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
..because -iname cannot be used to match paths.
Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
Reviewed-by: Leif Lindholm <leif@nuviainc.com>
Reviewed-by: Daniel Axtens <dja@axtens.net>
Support was implemented in commit c7cb11b21 (probe: Support probing for
msdos PARTUUID).
Signed-off-by: Jacob Kroon <jacob.kroon@gmail.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Like grub_verifiers_open(), the grub_verify_string() should also
display this debug message, which is very helpful for debugging.
Signed-off-by: Tianjia Zhang <tianjia.zhang@linux.alibaba.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
If an existing variable is set with a value whose length is smaller than
the current value, a memory corruption can happen due copying padding '#'
characters outside of the environment block buffer.
This is caused by a wrong calculation of the previous free space position
after moving backward the characters that followed the old variable value.
That position is calculated to fill the remaining of the buffer with the
padding '#' characters. But since isn't calculated correctly, it can lead
to copies outside of the buffer.
The issue can be reproduced by creating a variable with a large value and
then try to set a new value that is much smaller:
$ grub2-editenv --version
grub2-editenv (GRUB) 2.04
$ grub2-editenv env create
$ grub2-editenv env set a="$(for i in {1..500}; do var="b$var"; done; echo $var)"
$ wc -c env
1024 grubenv
$ grub2-editenv env set a="$(for i in {1..50}; do var="b$var"; done; echo $var)"
malloc(): corrupted top size
Aborted (core dumped)
$ wc -c env
0 grubenv
Reported-by: Renaud Métrich <rmetrich@redhat.com>
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Remove all documentation of and mentions of the uppermem
command from the docs/grub.texi file.
The uppermem command is not implemented in the GRUB source
at all and appears to never have been implemented despite
former plans to add an uppermem command.
To reduce user confusion, this even removes the paragraph
describing how GRUB's uppermem command was supposed to
complement the Linux kernel's mem= parameter.
Signed-off-by: Hans Ulrich Niedermann <hun@n-dimensional.de>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Remove the documentation of the pxe_unload command from the
docs/grub.texi file.
The pxe_unload command is not implemented in the grub source
at this time at all. It appears to have been removed in commit
671a78acb (cleanup pxe and efi network release).
Signed-off-by: Hans Ulrich Niedermann <hun@n-dimensional.de>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Add a few patterns to .gitignore to cover files which are generated
by building grub ("make", "make check", "make dist") but which have
been forgotten to add to .gitignore in the past.
Signed-off-by: Hans Ulrich Niedermann <hun@n-dimensional.de>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Going through the list of gitignore patterns without a leading slash,
this adds a leading slash where it appears to have been forgotten.
Some gitignore patterns like ".deps/" or "Makefile" clearly should
match everywhere, so those definitively need no leading slash.
For some patterns like "ascii.bitmaps", it is unclear where in the
source tree they should match. Those patterns are kept as they are,
matching the patterns in the whole tree of subdirectories.
Signed-off-by: Hans Ulrich Niedermann <hun@n-dimensional.de>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Add trailing slashes for all patterns matching directories.
Note that we do *not* add trailing slashes for *symlinks*
to directories.
Signed-off-by: Hans Ulrich Niedermann <hun@n-dimensional.de>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Alphabetically sort the two groups of gitignore patterns:
* The group of patterns without slashes, matching anywhere
in the directory subtree.
* The group of patterns with slashes, matching relative to the
.gitignore file's directory
Signed-off-by: Hans Ulrich Niedermann <hun@n-dimensional.de>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Group the .gitignore patterns into two groups:
* Pattern not including a slash, i.e. matching files anywhere in
the .gitignore file's directory and all of its subdirectories.
* Patterns including a slash, i.e. matching only relative to the
.gitignore file's directory.
Signed-off-by: Hans Ulrich Niedermann <hun@n-dimensional.de>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
As all gitignore patterns containing a left or middle slash match
only relative to the .gitignore file's directory, we write them
all in the same manner with a leading slash.
This makes the file significantly easier to read.
Signed-off-by: Hans Ulrich Niedermann <hun@n-dimensional.de>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Lack of them causes random instructions to be executed before the
jump really happens.
Signed-off-by: Vladimir Serbinenko <phcoder@google.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
