Enable the config REMAKE_ELF in xilinx_versal_mini_ospi_defconfig
and xilinx_versal_mini_qspi_defconfig which generates u-boot.elf.
This commit a8c281d4b737("Convert CONFIG_REMAKE_ELF to Kconfig")
misses to enable this config in these defconfigs.
Signed-off-by: Venkatesh Yadav Abbarapu <venkatesh.abbarapu@amd.com>
Link: https://lore.kernel.org/r/20221125084639.23835-1-venkatesh.abbarapu@amd.com
Signed-off-by: Michal Simek <michal.simek@amd.com>
The driver was using an incorrect value for GQSPI_LPBK_DLY_ADJ_DLY_1
tapdelay for Versal for frequencies above 100MHz. Change it from 2 to 1
based on the recommended value in IP spec.
Signed-off-by: T Karthik Reddy <t.karthik.reddy@xilinx.com>
Signed-off-by: Ashok Reddy Soma <ashok.reddy.soma@amd.com>
Reviewed-by: Dhruva Gole <d-gole@ti.com>
Link: https://lore.kernel.org/r/20221123090451.11409-1-ashok.reddy.soma@amd.com
Signed-off-by: Michal Simek <michal.simek@amd.com>
When Linux boot takes over control of the pmu
(by signaling PM_INIT_FINALIZE via ipi), pmu will switch off 'unused'
rpu cores. The Xilinx zynqmp fsbl prevents switching off those cores by
marking rpu cores as 'used' when loading code partitions to those cores.
The current u-boot SPL is missing this behaviour, which results in
halting rpu cores during Linux boot.
This commit mimics the xilinx zynqmp fsbl behavior by marking r5 cores as
used when they are released during boot.
Signed-off-by: Lukas Funke <lukas.funke@weidmueller.com>
Signed-off-by: Lukas Funke <lukas.funke-oss@weidmueller.com>
Link: https://lore.kernel.org/r/20221028121547.26464-2-lukas.funke-oss@weidmueller.com
Signed-off-by: Michal Simek <michal.simek@amd.com>
Both PCS/PMA PHY and the external PHY need to have a valid link status
in order to have Ethernet traffic. Check and wait this status at
setup_phy() so that we could diagnose if there is a PHY issue.
Signed-off-by: Andy Chiu <andy.chiu@sifive.com>
Reviewed-by: Greentime Hu <greentime.hu@sifive.com>
Link: https://lore.kernel.org/r/20221101035800.912644-3-andy.chiu@sifive.com
Signed-off-by: Michal Simek <michal.simek@amd.com>
If we bridge an external PHY to Xilinx's PCS/PMA PHY and would like to
get and set the real status of the PHY facing the external world. Then
we should phy_connect() to the external PHY instead of the PCS/PMA one.
Thus, we add a pcs-handle DT entry, which have been merged in Linux, and
leave the configuration of it to the driver itself.
Unlike Linux, where the PCS/PMA PHY is managed by phylink, managing the
PCS/PMA PHY is only internal to the driver in U-Boot. The PCS/PMA PHY
pressents only when the phy-mode is configured as SGMII or 1000Base-X,
so it is always 1 Gbps and full-duplex and we may skip passing link
information out.
Signed-off-by: Andy Chiu <andy.chiu@sifive.com>
Reviewed-by: Greentime Hu <greentime.hu@sifive.com>
Link: https://lore.kernel.org/r/20221101035800.912644-2-andy.chiu@sifive.com
Signed-off-by: Michal Simek <michal.simek@amd.com>
Documentation:
* describe DM firmware needed for j721e_evm
* describe management of UEFI security data base with eficonfig
UEFI:
* code clean-up for eficonfig command
* fix handling of DHCP aknowledge
* correct EFI memory type used for U-Boot code
* unit test for FatToStr() truncation
* add an EFI binary to print boot hart ID
Other:
* improve parameter checks in console functions
* fix variable initialization in blk_get_device_part_str
-----BEGIN PGP SIGNATURE-----
iQIzBAABCAAdFiEEbcT5xx8ppvoGt20zxIHbvCwFGsQFAmOKVdQACgkQxIHbvCwF
GsREQxAAlhx05eYwItq2n7oDV65h2yFl5YaGo35v9HPG8DrLoeOdw/IpNCQ+Naao
0VyIg+uFM/qvFTIwfC1NDVlzOiDBQgaFiUhe1Zvq8n8lJNdfAwgXvFQU5MOyxcDa
4RZBYpwN+kJ2+6P98xtl8jIOJZ7jO/BLcR7Xss9dP2B7IJcczMrj5Kl2heanXjnk
zhMHx8WC4rrSBZM4NxyPd6e04qxz1L1r0A6U0ZmVT1ferdaBb7LoXkQk4fINhI6a
Z+1UKzKvTWDynHmKuuK5ujFyBbE7COqVGnR6uabZxOk1CS7EEJJyDdzYA5F4yVlf
6DSDTzE72jhRPa7AQnYtwQA/+IPwkfRXo7n4eRERi135onm7ufy+aww/yeZ3RdJF
BN5BRhFmJPT/KfQK/JgDZ3aDDYFjdcB+h2nm57DWeKB0nq/xsAMHhJ4rrB2yu1kn
dmNP9v9EZtvp0wG2H4nIeXd7kKBGG4qZRqhfzBfNYQ899dubBEKUXv+DEfqSnh6k
3v4W0V8sPjjvY+2hgiYyBnmmJP/MEG0T21uppFC9AcUKfaSTElRqkRpr+wDkB5qL
xHwHuXYRBaMuhycs2W/6D1D3UaGg8YYzgOidMt0Pq0T+pq4V1bDXIlixE9nXZGl6
tqy3WKMcIu85AYYqwt0OZnF4DWx8v2pRLhyGbkSPVoadmeDEcmg=
=UmdO
-----END PGP SIGNATURE-----
Merge tag 'efi-2023-01-rc3' of https://source.denx.de/u-boot/custodians/u-boot-efi
Pull request for efi-2023-01-rc3
Documentation:
* describe DM firmware needed for j721e_evm
* describe management of UEFI security data base with eficonfig
UEFI:
* code clean-up for eficonfig command
* fix handling of DHCP aknowledge
* correct EFI memory type used for U-Boot code
* unit test for FatToStr() truncation
* add an EFI binary to print boot hart ID
Other:
* improve parameter checks in console functions
* fix variable initialization in blk_get_device_part_str
This commits adds the description for the UEFI Secure Boot
Configuration through the eficonfig menu.
Signed-off-by: Masahisa Kojima <masahisa.kojima@linaro.org>
Redacted the complete document.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
eficonfig command reads all possible UEFI load options
from 0x0000 to 0xFFFF to construct the menu. This takes too much
time in some environment.
This commit uses efi_get_next_variable_name_int() to read all
existing UEFI load options to significantlly reduce the count of
efi_get_var() call.
Signed-off-by: Masahisa Kojima <masahisa.kojima@linaro.org>
Some commands need to enumerate the existing UEFI load
option variable("Boot####"). This commit transfers some code
from cmd/efidebug.c to lib/efi_loder/, then exposes
efi_varname_is_load_option() function to check whether
the UEFI variable name is "Boot####".
Signed-off-by: Masahisa Kojima <masahisa.kojima@linaro.org>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Use u16_strsize() to simplify the u16 string buffer
size calculation.
Signed-off-by: Masahisa Kojima <masahisa.kojima@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
The directory name in eficonfig menu entry contains the
'\' separator. strcmp() argument ".." is wrong and one directory
up handling does not work correctly. strcmp() argument must
include '\' separator.
Signed-off-by: Masahisa Kojima <masahisa.kojima@linaro.org>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
EFI_LOADER_DATA/CODE is reserved for EFI applications.
Memory allocated by U-Boot for internal usage should be
EFI_BOOT_SERVICES_DATA or _CODE or EFI_RUNTIME_SERVICES_DATA or _CODE.
Reported-by: François-Frédéric Ozog <ff@ozog.com>
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: François-Frédéric Ozog <ff@ozog.com>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
The dhcp command may be executed after the first UEFI command.
We should still update the EFI_PXE_BASE_CODE_PROTOCOL.
Don't leak content of prior acknowledge packages.
Handle failing allocation when calling malloc().
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Provide an EFI binary that prints the boot hart ID as found in the
device-tree as /chosen/boot-hartid property and as provided by the
RISCV_EFI_BOOT_PROTOCOL.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
* BASH code should be labeled as such.
* Code blocks should be indented by 4 spaces.
Fix these here.
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: Andrew Davis <afd@ti.com>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
The symbol CONFIG_NET_DEVICES does not exist.
The correct name is CONFIG_NETDEVICES.
Fixes: 77b5c4a5b1 ("efi_loader: Let networking support depend on NETDEVICES")
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
blk_get_device_part_str() should always initialize all info fields
including sys_ind. As a side effect the code is simplified.
Replace '(0 ==' by '(!' to conform with Linux coding style.
Fixes: 4d907025d6 ("sandbox: restore ability to access host fs through standard commands")
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Heiko Schocher <hs@denx.de>
We use the parameter file in console functions to choose from an array
after checking against MAX_FILES but we never check if the value of file
is negative.
Running ./u-boot -T -l and issuing the poweroff command has resulted in
crashes because os_exit() results in std::ostream::flush() calling U-Boot's
fflush with file being a pointer which when converted to int may be
represented by a negative number.
This shows that checking against MAX_FILES is not enough. We have to ensure
that the file argument is always positive.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
- Add Peter Robinson as a co-custodian for Pi, update the maintainer
record for common/usb_storage.c, re-add bmp_logo to tools-only and fix
SPI booting on the SanCloud BBE
The SanCloud BBE requires the same dtb nodes to be present in the SPL as
the AM335x EVM.
The SanCloud BBE Lite also requires the SPI flash node and all
dependencies to be present in the SPL to support SPI boot.
Signed-off-by: Paul Barker <paul.barker@sancloud.com>
The advanced address translation provided by CONFIG_SPL_OF_TRANSLATE is
needed to determine the base address of the uart0 peripheral on am335x
platforms when CONFIG_SPL_OF_CONTROL is enabled.
If CONFIG_SPL_OF_CONTROL is enabled in the base (non-spiboot)
am335x_evm_defconfig, then CONFIG_SPL_OF_TRANSLATE will also need to be
enabled there. Unfortunately this cannot be done pre-emptively due to
the kconfig dependencies.
The TI clk-ctrl & TI sysc drivers are also required to bring up the SPI
bus on am335x platforms.
Signed-off-by: Paul Barker <paul.barker@sancloud.com>
For successful boot when CONFIG_SPL_OF_CONTROL=y, we need to ensure that
the board EEPROM on i2c0, the uart0 serial port and the relevant boot
device (mmc1 or mmc2) can be accessed in the SPL. We also need to
preserve the parent nodes for each required dtb node.
Signed-off-by: Paul Barker <paul.barker@sancloud.com>
The TI sysc bus driver is required to allow access to the SPI bus on
am335x platforms. To support SPI boot this driver needs to be enabled in
the SPL/TPL as appropriate.
Signed-off-by: Paul Barker <paul.barker@sancloud.com>
We should only perform additional iteration steps when needed to
initialize the parent of a device. Other binding errors (such as a
missing driver) should not lead to additional iteration steps.
Unnecessary iteration steps can cause issues when memory is tightly
constrained (such as in the TPL/SPL) since device_bind_by_name()
unconditionally allocates memory for a struct udevice. On the SanCloud
BBE this led to boot failure caused by memory exhaustion in the SPL
when booting from SPI flash.
Signed-off-by: Paul Barker <paul.barker@sancloud.com>
The usb_storage.c is the host-side USB mass storage device support,
it is not the DFU/UMS gadget-side implementation. Fix the entry.
Signed-off-by: Marek Vasut <marex@denx.de>
Pre 2023.01 the bmp_logo was built as part of the tools-only_defconfig
build, something changed and the VIDEO dep needed to build it
is no longer pulled in so fix that by explicitly defining it.
Signed-off-by: Peter Robinson <pbrobinson@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Peter accpeted to step up as a co-maintainer for the RPis.
Reflect that in the corresponding MAINTAINERS files.
Signed-off-by: Matthias Brugger <mbrugger@suse.com>
Reviewed-by: Peter Robinson <pbrobinson@gmail.com>
The signal name of pin PD8 with function D is A22_NANDCLE
as it is defined in the datasheet.
Fixes: 558378a4cd ("ARM: mach-at91: add support for new SoC sama7g5")
Signed-off-by: Mihai Sain <mihai.sain@microchip.com>
Add a driver for the Intel XWAY GbE PHY:
- configure RGMII using dt phy-mode and standard delay properties
- use genphy_config
Signed-off-by: Tim Harvey <tharvey@gateworks.com>
The rx descriptor list is in cached memory, and there may be multiple
descriptors per cache-line. After reclaim_rx_buffers marks a descriptor
as unused it does a cache flush, which causes the entire cache-line to
be written to memory, which may override other descriptors in the same
cache-line that the controller may have written to.
The fix skips freeing descriptors that are not the last in a cache-line,
and if the freed descriptor is the last one in a cache-line, it marks
all the descriptors in the cache-line as unused.
This is similarly to what is done in drivers/net/fec_mxc.c
In my case this bug caused tftpboot to fail some times when other
packets are sent to u-boot in addition to the ongoing tftp (e.g. ping).
The driver would stop receiving new packets because it is waiting
on a descriptor that is marked unused, when in reality the descriptor
contains a new unprocessed packet but while freeing the previous buffer
descriptor & flushing the cache, the driver accidentally marked the
descriptor as unused.
Signed-off-by: Yaron Micher <yaronm@hailo.ai>
Simulate a TCP HTTP server's response for testing wget command.
Signed-off-by: Ying-Chun Liu (PaulLiu) <paul.liu@linaro.org>
Cc: Christian Gmeiner <christian.gmeiner@gmail.com>
Cc: Joe Hershberger <joe.hershberger@ni.com>
Cc: Michal Simek <michal.simek@xilinx.com>
Cc: Ramon Fried <rfried.dev@gmail.com>
Cc: Simon Glass <sjg@chromium.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Ramon Fried <rfried.dev@gmail.com>
Add documentation for the wget command.
Signed-off-by: Ying-Chun Liu (PaulLiu) <paul.liu@linaro.org>
Cc: Christian Gmeiner <christian.gmeiner@gmail.com>
Cc: Joe Hershberger <joe.hershberger@ni.com>
Cc: Michal Simek <michal.simek@xilinx.com>
Cc: Ramon Fried <rfried.dev@gmail.com>
Cc: Simon Glass <sjg@chromium.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Ramon Fried <rfried.dev@gmail.com>
This commit adds a simple wget command that can download files
from http server.
The command syntax is
wget ${loadaddr} <path of the file from server>
Signed-off-by: Duncan Hare <DuncanCHare@yahoo.com>
Signed-off-by: Ying-Chun Liu (PaulLiu) <paul.liu@linaro.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Cc: Christian Gmeiner <christian.gmeiner@gmail.com>
Cc: Joe Hershberger <joe.hershberger@ni.com>
Cc: Michal Simek <michal.simek@xilinx.com>
Cc: Ramon Fried <rfried.dev@gmail.com>
Reviewed-by: Ramon Fried <rfried.dev@gmail.com>
Currently file transfers are done using tftp or NFS both
over udp. This requires a request to be sent from client
(u-boot) to the boot server.
The current standard is TCP with selective acknowledgment.
Signed-off-by: Duncan Hare <DH@Synoia.com>
Signed-off-by: Duncan Hare <DuncanCHare@yahoo.com>
Signed-off-by: Ying-Chun Liu (PaulLiu) <paul.liu@linaro.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Cc: Christian Gmeiner <christian.gmeiner@gmail.com>
Cc: Joe Hershberger <joe.hershberger@ni.com>
Cc: Michal Simek <michal.simek@xilinx.com>
Cc: Ramon Fried <rfried.dev@gmail.com>
Reviewed-by: Ramon Fried <rfried.dev@gmail.com>
Fix a couple of typos:
- s/Acquantia/Aquantia/
- s/firmare/firmware/
Signed-off-by: Tim Harvey <tharvey@gateworks.com>
Reviewed-by: Ramon Fried <rfried.dev@gmail.com>
With a suitable sequence of malicious packets, it's currently possible
to get a hole descriptor to contain arbitrary attacker-controlled
contents, and then with one more packet to use that as an arbitrary
write vector.
While one could possibly change the algorithm so we instead loop over
all holes, and in each hole puts as much of the current fragment as
belongs there (taking care to carefully update the hole list as
appropriate), it's not worth the complexity: In real, non-malicious
scenarios, one never gets overlapping fragments, and certainly not
fragments that would be supersets of one another.
So instead opt for this simple protection: Simply don't allow the
eventual memcpy() to write beyond the last_byte of the current hole.
Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
U-Boot does not support IP fragmentation on TX (and unless
CONFIG_IP_DEFRAG is set, neither on RX). So the blocks we send must
fit in a single ethernet packet.
Currently, if tftpblocksize is set to something like 5000 and I
tftpput a large enough file, U-Boot crashes because we overflow
net_tx_packet (which only has room for 1500 bytes plus change).
Similarly, if tftpblocksize is set to something larger than what we
can actually receive (e.g. 50000, with NET_MAXDEFRAG being 16384), any
tftp get just hangs because we never receive any packets.
Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
Reviewed-by: Ramon Fried <rfried.dev@gmail.com>
Nothing inside this block depends on NET_TFTP_VARS to be set to parse
correctly. Switch to C if() in preparation for adding code before
this (to avoid a declaration-after-statement warning).
Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
[trini: Update to cover CONFIG_TFTP_PORT case as well]
Signed-off-by: Tom Rini <trini@konsulko.com>
For some reason, the ip_len field in a reassembled IP datagram is set
to just the size of the payload, but it should be set to the value it
would have had if the datagram had never been fragmented in the first
place, i.e. size of payload plus size of IP header.
That latter value is currently returned correctly via the "len"
variable. And before entering net_defragment(), len does have the
value ntohs(ip->ip_len), so if we're not dealing with a
fragment (so net_defragment leaves *len alone), that relationship of
course also holds after the net_defragment() call.
The only use I can find of ip->ip_len after the net_defragment call is
the ntohs(ip->udp_len) > ntohs(ip->ip_len) sanity check - none of the
functions that are passed the "ip" pointer themselves inspect ->ip_len
but instead use the passed len.
But that sanity check is a bit odd, since the RHS really should be
"ntohs(ip->ip_len) - 20", i.e. the IP payload size.
Now that we've fixed things so that len == ntohs(ip->ip_len) in all
cases, change that sanity check to use len-20 as the RHS.
Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
I hit a strange problem with v2022.10: Sometimes my tftp transfer
would seemingly just hang. It only happened for some files. Moreover,
changing tftpblocksize from 65464 to 65460 or 65000 made it work again
for all the files I tried. So I started suspecting it had something to
do with the file sizes and in particular the way the tftp blocks get
fragmented and reassembled.
v2022.01 showed no problems with any of the files or any value of
tftpblocksize.
Looking at what had changed in net.c or tftp.c since January showed
only one remotely interesting thing, b85d130ea0.
So I fired up wireshark on my host to see if somehow one of the
packets would be too small. But no, with both v2022.01 and v2022.10,
the exact same sequence of packets were sent, all but the last of size
1500, and the last being 1280 bytes.
But then it struck me that 1280 is 5*256, so one of the two bytes
on-the-wire is 0 and the other is 5, and when then looking at the code
again the lack of endianness conversion becomes obvious. [ntohs is
both applied to ip->ip_off just above, as well as to ip->ip_len just a
little further down when the "len" is actually computed].
IOWs the current code would falsely reject any packet which happens to
be a multiple of 256 bytes in size, breaking tftp transfers somewhat
randomly, and if it did get one of those "malicious" packets with
ip_len set to, say, 27, it would be seen by this check as being 6912
and hence not rejected.
====
Now, just adding the missing ntohs() would make my initial problem go
away, in that I can now download the file where the last fragment ends
up being 1280 bytes. But there's another bug in the code and/or
analysis: The right-hand side is too strict, in that it is ok for the
last fragment not to have a multiple of 8 bytes as payload - it really
must be ok, because nothing in the IP spec says that IP datagrams must
have a multiple of 8 bytes as payload. And comments in the code also
mention this.
To fix that, replace the comparison with <= IP_HDR_SIZE and add
another check that len is actually a multiple of 8 when the "more
fragments" bit is set - which it necessarily is for the case where
offset8 ends up being 0, since we're only called when
(ip_off & (IP_OFFS | IP_FLAGS_MFRAG)).
====
So, does this fix CVE-2022-30790 for real? It certainly correctly
rejects the POC code which relies on sending a packet of size 27 with
the MFRAG flag set. Can the attack be carried out with a size 27
packet that doesn't set MFRAG (hence must set a non-zero fragment
offset)? I dunno. If we get a packet without MFRAG, we update
h->last_byte in the hole we've found to be start+len, hence we'd enter
one of
if ((h >= thisfrag) && (h->last_byte <= start + len)) {
or
} else if (h->last_byte <= start + len) {
and thus won't reach any of the
/* overlaps with initial part of the hole: move this hole */
newh = thisfrag + (len / 8);
/* fragment sits in the middle: split the hole */
newh = thisfrag + (len / 8);
IOW these division are now guaranteed to be exact, and thus I think
the scenario in CVE-2022-30790 cannot happen anymore.
====
However, there's a big elephant in the room, which has always been
spelled out in the comments, and which makes me believe that one can
still cause mayhem even with packets whose payloads are all 8-byte
aligned:
This code doesn't deal with a fragment that overlaps with two
different holes (thus being a superset of a previously-received
fragment).
Suppose each character below represents 8 bytes, with D being already
received data, H being a hole descriptor (struct hole), h being
non-populated chunks, and P representing where the payload of a just
received packet should go:
DDDHhhhhDDDDHhhhDDDD
PPPPPPPPP
I'm pretty sure in this case we'd end up with h being the first hole,
enter the simple
} else if (h->last_byte <= start + len) {
/* overlaps with final part of the hole: shorten this hole */
h->last_byte = start;
case, and thus in the memcpy happily overwrite the second H with our
chosen payload. This is probably worth fixing...
Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
While the code mostly/only handles UDP packets, it's possible for the
last fragment of a fragmented UDP packet to be smaller than 28 bytes;
it can be as small as 21 bytes (an IP header plus one byte of
payload). So until we've performed the defragmentation step and thus
know whether we're now holding a full packet, we should only check for
the existence of the fields in the ip header, i.e. that there are at
least 20 bytes present.
In practice, we always seem to be handed a "len" of minimum 60 from the
device layer, i.e. minimal ethernet frame length minus FCS, so this is
mostly theoretical.
After we've fetched the header's claimed length and used that to
update the len variable, check that the header itself claims to be the
minimal possible length.
This is probably how CVE-2022-30552 should have been dealt with in the
first place, because net_defragment() is not the only place that wants
to know the size of the IP datagram payload: If we receive a
non-fragmented ICMP packet, we pass "len" to receive_icmp() which in
turn may pass it to ping_receive() which does
compute_ip_checksum(icmph, len - IP_HDR_SIZE)
and due to the signature of compute_ip_checksum(), that would then
lead to accessing ~4G of address space, very likely leading to a
crash.
Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
