Portions of the code attempted to handle the fact that GPT entries on
disk may be larger than the currently defined struct while others
assumed the data could be indexed by the struct size directly. This
never came up because no utility uses a size larger than 128 bytes but
for the sake of safety we need to do this by the spec.
GPT_BOTH_VALID is 4 bits so simple a boolean check is not sufficient.
This broken condition allowed gptprio to trust bogus disk locations in
headers that were marked invalid causing arbitrary disk corruption.
We may get more than one response before exiting out of loop in
grub_net_dns_lookup, but buffer was allocated for the first response only,
so storing answers from subsequent replies wrote past allocated size.
We never really use more than the very first address during lookup so there
is little point in collecting all of them. Just quit early if we already have
some reply.
Code needs serious redesign to actually collect multiple answers
and select the best fit according to requested type (IPv4 or IPv6).
Reported and tested by Michael Chang <mchang@suse.com>
XFS V5 stores UUID in metadata and compares them with superblock UUID.
To allow changing of user-visible UUID it stores original value in new
superblock field (meta_uuid) and sets incompatible flag to indicate that
new field must be used to verify metadata. Our driver currently does not
check metadata UUID so simply accept such filesystem.
Reported-By: Marcos Mello <marcosfrm@outlook.com>
Reviewd by Jan Kara <jack@suse.cz>
GRUB assumes that no disk is ever larger than 1EiB and rejects
reads/writes to such locations. Unfortunately this is not conveyed in
the usual way with the special GRUB_DISK_SIZE_UNKNOWN value.
send client arch in bootp requests, for now BIOS and x64/aarch64 EFI is
supported.
fix a bug introduced in 4d5d7be005 where
user class was encoded improperly, although this didn't seem to have any
detrimental effects.
properly insert an option terminator.
If we open new connection, we need to reset stall indication, otherwise
nothing will ever be polled (low level code rely on this field being
zero when establishing connection).
Depending on the OS/libc, device macros are defined in different
headers. This change ensures we include the right one.
sys/types.h - BSD
sys/mkdev.h - Sun
sys/sysmacros.h - glibc (Linux)
glibc currently pulls sys/sysmacros.h into sys/types.h, but this may
change in a future release.
https://sourceware.org/ml/libc-alpha/2015-11/msg00253.html
At least the apache sever is very unhappy with that extra null line and will
take more than ten seconds in responding to each range request, which slows
down a lot the entire http file transfer process or even time out.
Some DHCP servers (such as dnsmasq) tokenise parameters with commas, making
it impossible to pass boot files with commas in them. Allow using a semicolon
to separate the protocol from host if a comma wasn't found.
The current logic in the DNS resolution code allocates an address buffer
based on the number of addresses in the response packet. If we receive
multiple response packets in response to a single query packet, this means
that we will reallocate a new buffer large enough for only the addresses in
that specific packet, discarding any previous results in the process. Worse,
we still keep track of the *total* number of addresses resolved in response
to this query, not merely the number in the packet being currently processed.
Use realloc() rather than malloc() to avoid overwriting the existing data,
and allocate a buffer large enough for the total set of addresses rather
than merely the number in this specific response.
Rework TPM measurements to use fewer PCRs. After discussion with upstream,
it's preferable to avoid using so many PCRs. Instead, measure into PCRs 8
and 9 but use a prefix in the event log to indicate which subsystem carried
out the measurements.
OpenBSD 5.9 apparently defaults to -fpie. We use -fno-PIE when appropriate
already, but that is not enough - it does not turn off -fpie.
Actually check for -fPIE is not precise enough. __PIE__ is set for both
-fpie and -fPIE but with different values. As far as I can tell, both
options were introduced at the same time, so both should always be supported.
This fixes compilation on OpenBSD 5.9 which otherwise created insanely big
lzma_decompress.img.
Reported, suggested and tested by: Jiri B <jirib@devio.us>
