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>
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>
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>
Currently the string functions grub_strtol(), grub_strtoul(), and
grub_strtoull() don't declare the "end" pointer in such a way as to
require the pointer itself or the character array to be immutable to the
implementation, nor does the C standard do so in its similar functions,
though it does require us not to change any of it.
The typical declarations of these functions follow this pattern:
long
strtol(const char * restrict nptr, char ** restrict endptr, int base);
Much of the reason for this is historic, and a discussion of that
follows below, after the explanation of this change. (GRUB currently
does not include the "restrict" qualifiers, and we name the arguments a
bit differently.)
The implementation is semantically required to treat the character array
as immutable, but such accidental modifications aren't stopped by the
compiler, and the semantics for both the callers and the implementation
of these functions are sometimes also helped by adding that requirement.
This patch changes these declarations to follow this pattern instead:
long
strtol(const char * restrict nptr,
const char ** const restrict endptr,
int base);
This means that if any modification to these functions accidentally
introduces either an errant modification to the underlying character
array, or an accidental assignment to endptr rather than *endptr, the
compiler should generate an error. (The two uses of "restrict" in this
case basically mean strtol() isn't allowed to modify the character array
by going through *endptr, and endptr isn't allowed to point inside the
array.)
It also means the typical use case changes to:
char *s = ...;
const char *end;
long l;
l = strtol(s, &end, 10);
Or even:
const char *p = str;
while (p && *p) {
long l = strtol(p, &p, 10);
...
}
This fixes 26 places where we discard our attempts at treating the data
safely by doing:
const char *p = str;
long l;
l = strtol(p, (char **)&ptr, 10);
It also adds 5 places where we do:
char *p = str;
while (p && *p) {
long l = strtol(p, (const char ** const)&p, 10);
...
/* more calls that need p not to be pointer-to-const */
}
While moderately distasteful, this is a better problem to have.
With one minor exception, I have tested that all of this compiles
without relevant warnings or errors, and that /much/ of it behaves
correctly, with gcc 9 using 'gcc -W -Wall -Wextra'. The one exception
is the changes in grub-core/osdep/aros/hostdisk.c , which I have no idea
how to build.
Because the C standard defined type-qualifiers in a way that can be
confusing, in the past there's been a slow but fairly regular stream of
churn within our patches, which add and remove the const qualifier in many
of the users of these functions. This change should help avoid that in
the future, and in order to help ensure this, I've added an explanation
in misc.h so that when someone does get a compiler warning about a type
error, they have the fix at hand.
The reason we don't have "const" in these calls in the standard is
purely anachronistic: C78 (de facto) did not have type qualifiers in the
syntax, and the "const" type qualifier was added for C89 (I think; it
may have been later). strtol() appears to date from 4.3BSD in 1986,
which means it could not be added to those functions in the standard
without breaking compatibility, which is usually avoided.
The syntax chosen for type qualifiers is what has led to the churn
regarding usage of const, and is especially confusing on string
functions due to the lack of a string type. Quoting from C99, the
syntax is:
declarator:
pointer[opt] direct-declarator
direct-declarator:
identifier
( declarator )
direct-declarator [ type-qualifier-list[opt] assignment-expression[opt] ]
...
direct-declarator [ type-qualifier-list[opt] * ]
...
pointer:
* type-qualifier-list[opt]
* type-qualifier-list[opt] pointer
type-qualifier-list:
type-qualifier
type-qualifier-list type-qualifier
...
type-qualifier:
const
restrict
volatile
So the examples go like:
const char foo; // immutable object
const char *foo; // mutable pointer to object
char * const foo; // immutable pointer to mutable object
const char * const foo; // immutable pointer to immutable object
const char const * const foo; // XXX extra const keyword in the middle
const char * const * const foo; // immutable pointer to immutable
// pointer to immutable object
const char ** const foo; // immutable pointer to mutable pointer
// to immutable object
Making const left-associative for * and right-associative for everything
else may not have been the best choice ever, but here we are, and the
inevitable result is people using trying to use const (as they should!),
putting it at the wrong place, fighting with the compiler for a bit, and
then either removing it or typecasting something in a bad way. I won't
go into describing restrict, but its syntax has exactly the same issue
as with const.
Anyway, the last example above actually represents the *behavior* that's
required of strtol()-like functions, so that's our choice for the "end"
pointer.
Signed-off-by: Peter Jones <pjones@redhat.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
This patch implements a search for a specific configuration when the config
file is on a remoteserver. It uses the following order:
1) DHCP client UUID option.
2) MAC address (in lower case hexadecimal with dash separators);
3) IP (in upper case hexadecimal) or IPv6;
4) The original grub.cfg file.
This procedure is similar to what is used by pxelinux and yaboot:
http://www.syslinux.org/wiki/index.php/PXELINUX#config
It is enabled by default but can be disabled by setting the environment
variable "feature_net_search_cfg" to "n" in an embedded configuration.
Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=873406
Signed-off-by: Paulo Flabiano Smorigo <pfsmorigo@br.ibm.com>
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
This patch sets a net_<interface>_clientid and net_<interface>_clientuuid
GRUB environment variables, using the DHCP client ID and UUID options if
these are found.
In the same way than net_<interface>_<option> variables are set for other
options such domain name, boot file, next server, etc.
Signed-off-by: Paulo Flabiano Smorigo <pfsmorigo@br.ibm.com>
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Some TFTP servers do not handle multiple consecutive slashes correctly.
This patch avoids sending TFTP requests with non-normalized paths.
Signed-off-by: Lenny Szubowicz <lszubowi@redhat.com>
Signed-off-by: Mark Salter <msalter@redhat.com>
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Don't free file->data on receiving FIN flag since it is used all over
without checking. http_close() will be called later to free that memory.
Fixes bug: https://bugzilla.redhat.com/show_bug.cgi?id=860834
Signed-off-by: Gustavo Luiz Duarte <gustavold@linux.vnet.ibm.com>
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Mostly for cosmetic reasons, we add a "net_dhcp" command, which is (at the
moment) identical to the existing "net_bootp" command. Both actually trigger
a DHCP handshake now, and both should be able to deal with pure BOOTP servers.
We could think about dropping the DHCP options from the initial DISCOVER packet
when the user issues the net_bootp command, but it's unclear whether this is
really useful, as both protocols should be able to coexist.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Even though we were parsing some DHCP options sent by the server, so far
we are only using the BOOTP 2-way handshake, even when talking to a DHCP
server.
Change this by actually sending out DHCP DISCOVER packets instead of the
generic (mostly empty) BOOTP BOOTREQUEST packets.
A pure BOOTP server would ignore the extra DHCP options in the DISCOVER
packet and would just reply with a BOOTREPLY packet, which we also
handle in the code.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
In respone to a BOOTREQUEST packet a BOOTP server would answer with a BOOTREPLY
packet, which ends the conversation for good. DHCP uses a 4-way handshake,
where the initial server respone is an OFFER, which has to be answered with
REQUEST by the client again, only to be completed by an ACKNOWLEDGE packet
from the server.
Teach the grub_net_process_dhcp() function to deal with OFFER packets,
and treat ACK packets the same es BOOTREPLY packets.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The BOOTP RFC describes the boot file name and the server name as being part
of the integral BOOTP data structure, with some limits on the size of them.
DHCP extends this by allowing them to be separate DHCP options, which is more
flexible.
Teach the code dealing with those fields to check for those DHCP options first
and use this information, if provided. We fall back to using the BOOTP
information if those options are not used.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Currently we have a global timeout for all network cards in the BOOTP/DHCP
discovery process.
Make this timeout a per-interface one, so better accommodate the upcoming
4-way DHCP handshake and to also cover the lease time limit a DHCP offer
will come with.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Change the interface of the function dealing with incoming BOOTP packets
to take an interface instead of a card, to allow more fine per-interface
state (timeout, handshake state) later on.
Use the opportunity to clean up the code a bit.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
In contrast to BOOTP, DHCP uses a 4-way handshake, so requires to send
packets more often.
Refactor the generation and sending of the BOOTREQUEST packet into
a separate function, so that future code can more easily reuse this.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
DHCP specifies a special dummy option OVERLOAD, to allow DHCP options to
spill over into the (legacy) BOOTFILE and SNAME fields.
Parse and handle this option properly.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
For proper DHCP support we will need to parse DHCP options from a packet
more often and at various places.
Refactor the option parsing into a new function, which will scan a packet to
find *a particular* option field. Use that new function in places where we
were dealing with DHCP options before.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The comment is right, the "giaddr" fields holds the IP address of the BOOTP
relay, not a general purpose router address. Just remove the commented code,
archeologists can find it in the git history.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The grub_ieee1275_parse_bootpath() function (commit a661a32, ofnet: Initialize
structs in bootpath parser) introduces a build regression on SPARC:
cc1: warnings being treated as errors
net/drivers/ieee1275/ofnet.c: In function 'grub_ieee1275_parse_bootpath':
net/drivers/ieee1275/ofnet.c:156: error: missing initializer
net/drivers/ieee1275/ofnet.c:156: error: (near initialization for 'client_addr.type')
net/drivers/ieee1275/ofnet.c:156: error: missing initializer
net/drivers/ieee1275/ofnet.c:156: error: (near initialization for 'gateway_addr.type')
net/drivers/ieee1275/ofnet.c:156: error: missing initializer
net/drivers/ieee1275/ofnet.c:156: error: (near initialization for 'subnet_mask.type')
net/drivers/ieee1275/ofnet.c:157: error: missing initializer
net/drivers/ieee1275/ofnet.c:157: error: (near initialization for 'hw_addr.type')
make[3]: *** [net/drivers/ieee1275/ofnet_module-ofnet.o] Error 1
Initialize the entire structure.
More info can be found here:
http://lists.gnu.org/archive/html/grub-devel/2018-03/msg00034.html
Signed-off-by: Eric Snowberg <eric.snowberg@oracle.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Code later on checks if variables inside the struct are
0 to see if they have been set, like if there were addresses
in the bootpath.
The variables were not initialized however, so the check
might succeed with uninitialized data, and a new interface
with random addresses and the same name is added. This causes
$net_default_mac to point to the random one, so, for example,
using that variable to load per-mac config files fails.
Bug-Ubuntu: https://bugs.launchpad.net/bugs/1785859
Signed-off-by: Julian Andres Klode <julian.klode@canonical.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
This patch adds support for virtual LAN (VLAN) tagging. VLAN tagging allows
multiple VLANs in a bridged network to share the same physical network link
but maintain isolation:
http://en.wikipedia.org/wiki/IEEE_802.1Q
* grub-core/net/ethernet.c: Add check, get, and set vlan tag id.
* grub-core/net/drivers/ieee1275/ofnet.c: Get vlan tag id from bootargs.
* grub-core/net/arp.c: Add check.
* grub-core/net/ip.c: Likewise.
* include/grub/net/arp.h: Add vlantag attribute.
* include/grub/net/ip.h: Likewise.
get_card_packet() from ofnet.c allocates a netbuff based on the device's MTU:
nb = grub_netbuff_alloc (dev->mtu + 64 + 2);
In the case when the MTU is large, and the received packet is
relatively small, this leads to allocation of significantly more memory,
than it's required. An example could be transmission of TFTP packets
with 0x400 blksize via a network card with 0x10000 MTU.
This patch implements a per-card receive buffer in a way similar to efinet.c,
and makes get_card_packet() allocate a netbuff of the received data size.
Signed-off-by: Stanislav Kholmanskikh <stanislav.kholmanskikh@oracle.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
In the current code search_net_devices() uses the "alloc-mem" command
from the IEEE1275 User Interface for allocation of the transmit buffer
for the case when GRUB_IEEE1275_FLAG_VIRT_TO_REAL_BROKEN is set.
I don't have hardware where this flag is set to verify if this
workaround is still needed. However, further changes to ofnet will
require to execute this workaround one more time. Therefore, to
avoid possible duplication of code I'm moving this piece of
code into a function.
Signed-off-by: Stanislav Kholmanskikh <stanislav.kholmanskikh@oracle.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Network boot autoconfiguration sets default server to next server IP
(siaddr) from BOOTP/DHCP reply, but manual configuration using net_bootp
exports only server name. Unfortunately semantic of server name is not
clearly defined. BOOTP RFC 951 defines it only for client request, and
DHCP RFC 1541 only mentions it, without any implied usage. It looks like
this field is mostly empty in server replies.
Export next server IP as net_<interface>_next_server variable. This allows
grub configuration script to set $root/$prefix based on information obtained
by net_bootp.
Reported and tested by: Nikunj A Dadhania <nikunj@linux.vnet.ibm.com>
Cc: nikunj@linux.vnet.ibm.com
v2: change variable name to net_<interface>_next_server as discussed on the list
limit_time underflows when current time is less than 90000ms.
This causes packet fragments received during this time, i.e.,
till 90000ms pass since timer init, to be rejected.
Hence, set it to 0 if its less than 90000.
Signed-off-by: Sakar Arora <Sakar.Arora@nxp.com>
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>
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).
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.
ipv6 routing in grub2 is broken, we cannot talk to anything outside our local
network or anything that doesn't route in our global namespace. This patch
fixes this by doing a couple of things
1) Read the router information off of the router advertisement. If we have a
router lifetime we need to take the source address and create a route from it.
2) Changes the routing stuff slightly to allow you to specify a gateway _and_ an
interface. Since the router advertisements come in on the link local address we
need to associate it with the global address on the card. So when we are
processing the router advertisement, either use the SLAAC interface we create
and add the route to that interface, or loop through the global addresses we
currently have on our interface and associate it with one of those addresses.
We need to have a special case here for the default route so that it gets used,
we do this by setting the masksize to 0 to mean it encompasses all networks.
The routing code will automatically select the best route so if there is a
closer match we will use that.
With this patch I can now talk to ipv6 addresses outside of my local network.
Thanks,
Signed-off-by: Josef Bacik <jbacik@fb.com>
server cannot be NULL at this point (we return error earlier if it is).
Also structure is zalloc'ed, so no need to explicitly initialize
members to 0.
Found by: Coverity scan.
CID: 73837
While adding tcp window scaling support I was finding that I'd get some packet
loss or reordering when transferring from large distances and grub would just
timeout. This is because we weren't ack'ing when we got our OOO packet, so the
sender didn't know it needed to retransmit anything, so eventually it would fill
the window and stop transmitting, and we'd time out. Fix this by ACK'ing when
we don't find our next sequence numbered packet. With this fix I no longer time
out. Thanks,
Signed-off-by: Josef Bacik <jbacik@fb.com>
We were resetting nb->data every time we tried a new server, but we need to do
it every time we try for a different record, otherwise we don't end up falling
back to the A record properly. Thanks,
Signed-off-by: Josef Bacik <jbacik@fb.com>
sun4v vnet devices do not implement the support of duplex and speed
instance attributes. An attempt to open such a device with
the attributes will fail:
ok select net:speed=auto,duplex=auto
Unknown key 'speed'
Unknown key 'duplex'
Manual Configuration: Host IP, boot server and filename must be specified
WARNING: /virtual-devices@100/channel-devices@200/network@0: Can't open OBP standard TFTP package
Can't open device
ok
Therefore, let's not set SUFFIX for such devices.
Signed-off-by: Stanislav Kholmanskikh <stanislav.kholmanskikh@oracle.com>
The EFI spec indicates that get_status() should return the address of the buffer
we passed into transmit to indicate the the buffer was transmitted. However we
have boxes where the firmware returns some arbitrary address instead, which
makes grub think that we've not sent anything. So since we have the SNP stuff
opened in exclusive mode just assume any non-NULL txbuf means that our transmit
occurred properly. This makes grub able to do its networking stuff properly on
our broken firmware. Thanks,
cc: Peter Jones <pjones@redhat.com>
Signed-off-by: Josef Bacik <jbacik@fb.com>
Exclusive open on SNP will close all existing protocol instances which
may disable all receive filters on interface. Reinstall them after we
opened protocol exclusively.
Also follow UEFI specification recommendation and stop interfaces when
closing them:
Unexpected system errors, reboots and hangs can occur if an OS is loaded
and the network devices are not Shutdown() and Stopped().
Also by: Mark Salter <msalter@redhat.com>
Closes: 45204
From RFC1542:
The 'giaddr' field is rather poorly named. It exists to facilitate
the transfer of BOOTREQUEST messages from a client, through BOOTP
relay agents, to servers on different networks than the client.
Similarly, it facilitates the delivery of BOOTREPLY messages from the
servers, through BOOTP relay agents, back to the client. In no case
does it represent a general IP router to be used by the client. A
BOOTP client MUST set the 'giaddr' field to zero (0.0.0.0) in all
BOOTREQUEST messages it generates.
A BOOTP client MUST NOT interpret the 'giaddr' field of a BOOTREPLY
message to be the IP address of an IP router. A BOOTP client SHOULD
completely ignore the contents of the 'giaddr' field in BOOTREPLY
messages.
Leave code ifdef'd out for the time being in case we see regression.
Suggested by: Rink Springer <rink@rink.nu>
Closes: 43396
EDK2 network stack is based on Managed Network Protocol which is layered
on top of Simple Management Protocol and does background polling. This
polling races with grub for received (and probably trasmitted) packets
which causes either serious slowdown or complete failure to load files.
Open SNP device exclusively. This destroys all child MNP instances and
stops background polling.
Exclusive open cannot be done when enumerating cards, as it would destroy
PXE information we need to autoconfigure interface; and it cannot be done
during autoconfiguration as we need to do it for non-PXE boot as well. So
move SNP open to card ->open method and add matching ->close to clean up.
Based on patch from Mark Salter <msalter@redhat.com>
Also-By: Mark Salter <msalter@redhat.com>
Closes: 41731
EDK2 PXE driver creates two child devices - IPv4 and IPv6 - with
bound SNP instance. This means we get three cards for every physical
adapter when enumerating. Not only is this confusing, this may result
in grub ignoring packets that come in via the "wrong" card.
Example of device hierarchy is
Ctrl[91] PciRoot(0x0)/Pci(0x3,0x0)
Ctrl[95] PciRoot(0x0)/Pci(0x3,0x0)/MAC(525400123456,0x1)
Ctrl[B4] PciRoot(0x0)/Pci(0x3,0x0)/MAC(525400123456,0x1)/IPv4(0.0.0.0)
Ctrl[BC] PciRoot(0x0)/Pci(0x3,0x0)/MAC(525400123456,0x1)/IPv6(0000:0000:0000:0000:0000:0000:0000:0000)
Skip PXE created virtual devices when enumerating cards. Make sure to
find real card when applying initial autoconfiguration during PXE boot,
this information is associated with one of child devices.
