May 2022 - U-Boot

[PATCH v1 0/8] Introduce HPE GXP Architecture
by nick.hawkins＠hpe.com 26 May '22

26 May '22

From: Nick Hawkins <nick.hawkins(a)hpe.com> The GXP is the HPE BMC SoC that is used in the majority of HPE current generation servers. Traditionally the asic will last multiple generations of server before being replaced. Info about SoC: HPE GXP is the name of the HPE SoC. This SoC is used to implement many BMC features at HPE. It supports ARMv7 architecture based on the Cortex A9 core. It is capable of using an AXI bus to which a memory controller is attached. It has multiple SPI interfaces to connect boot flash and BIOS flash. It uses a 10/100/1000 MAC for network connectivity. It has multiple i2c engines to drive connectivity with a host infrastructure. The initial patches enable the timer and enable U-Boot prompt to work. Nick Hawkins (8): timer: gxp: Add HPE GXP timer support board: hpe: gxp: add HPE GXP soc support dt-bindings: arm: hpe: add GXP Support dt-bindings: timer: Add hpe gxp timer ARM: dts: Add device tree files for hpe gxp soc configs: gxp: add core support configs: gxp: add gxp_defconfig MAINTAINERS: Introduce HPE GXP Architecture MAINTAINERS | 12 +++ arch/arm/dts/Makefile | 2 + arch/arm/dts/hpe-bmc-dl360gen10.dts | 26 +++++ arch/arm/dts/hpe-gxp.dtsi | 95 ++++++++++++++++++ board/hpe/gxp/Kconfig | 47 +++++++++ board/hpe/gxp/Makefile | 1 + board/hpe/gxp/gxp_board.c | 33 +++++++ configs/gxp_defconfig | 48 ++++++++++ doc/device-tree-bindings/arm/hpe,gxp.yaml | 27 ++++++ .../timer/hpe,gxp-timer.yaml | 47 +++++++++ drivers/timer/Kconfig | 7 ++ drivers/timer/Makefile | 1 + drivers/timer/gxp-timer.c | 65 +++++++++++++ include/configs/gxp.h | 96 +++++++++++++++++++ 14 files changed, 507 insertions(+) create mode 100644 arch/arm/dts/hpe-bmc-dl360gen10.dts create mode 100644 arch/arm/dts/hpe-gxp.dtsi create mode 100644 board/hpe/gxp/Kconfig create mode 100644 board/hpe/gxp/Makefile create mode 100644 board/hpe/gxp/gxp_board.c create mode 100644 configs/gxp_defconfig create mode 100644 doc/device-tree-bindings/arm/hpe,gxp.yaml create mode 100644 doc/device-tree-bindings/timer/hpe,gxp-timer.yaml create mode 100644 drivers/timer/gxp-timer.c create mode 100644 include/configs/gxp.h -- 2.17.1

1 0

[PATCH v3] net: Check for the minimum IP header total length
by Fabio Estevam 26 May '22

26 May '22

From: Fabio Estevam <festevam(a)denx.de> Nicolas Bidron and Nicolas Guigo reported the two bugs below: " ----------BUG 1---------- In compiled versions of U-Boot that define CONFIG_IP_DEFRAG, a value of `ip->ip_len` (IP packet header's Total Length) higher than `IP_HDR_SIZE` and strictly lower than `IP_HDR_SIZE+8` will lead to a value for `len` comprised between `0` and `7`. This will ultimately result in a truncated division by `8` resulting value of `0` forcing the hole metadata and fragment to point to the same location. The subsequent memcopy will overwrite the hole metadata with the fragment data. Through a second fragment, this can be exploited to write to an arbitrary offset controlled by that overwritten hole metadata value. This bug is only exploitable locally as it requires crafting two packets the first of which would most likely be dropped through routing due to its unexpectedly low Total Length. However, this bug can potentially be exploited to root linux based embedded devices locally. ```C static struct ip_udp_hdr *__net_defragment(struct ip_udp_hdr *ip, int *lenp) { static uchar pkt_buff[IP_PKTSIZE] __aligned(PKTALIGN); static u16 first_hole, total_len; struct hole *payload, *thisfrag, *h, *newh; struct ip_udp_hdr *localip = (struct ip_udp_hdr *)pkt_buff; uchar *indata = (uchar *)ip; int offset8, start, len, done = 0; u16 ip_off = ntohs(ip->ip_off); /* payload starts after IP header, this fragment is in there */ payload = (struct hole *)(pkt_buff + IP_HDR_SIZE); offset8 = (ip_off & IP_OFFS); thisfrag = payload + offset8; start = offset8 * 8; len = ntohs(ip->ip_len) - IP_HDR_SIZE; ``` The last line of the previous excerpt from `u-boot/net/net.c` shows how the attacker can control the value of `len` to be strictly lower than `8` by issuing a packet with `ip_len` between `21` and `27` (`IP_HDR_SIZE` has a value of `20`). Also note that `offset8` here is `0` which leads to `thisfrag = payload`. ```C } else if (h >= thisfrag) { /* overlaps with initial part of the hole: move this hole */ newh = thisfrag + (len / 8); *newh = *h; h = newh; if (h->next_hole) payload[h->next_hole].prev_hole = (h - payload); if (h->prev_hole) payload[h->prev_hole].next_hole = (h - payload); else first_hole = (h - payload); } else { ``` Lower down the same function, execution reaches the above code path. Here, `len / 8` evaluates to `0` leading to `newh = thisfrag`. Also note that `first_hole` here is `0` since `h` and `payload` point to the same location. ```C /* finally copy this fragment and possibly return whole packet */ memcpy((uchar *)thisfrag, indata + IP_HDR_SIZE, len); ``` Finally, in the above excerpt the `memcpy` overwrites the hole metadata since `thisfrag` and `h` both point to the same location. The hole metadata is effectively overwritten with arbitrary data from the fragmented IP packet data. If `len` was crafted to be `6`, `last_byte`, `next_hole`, and `prev_hole` of the `first_hole` can be controlled by the attacker. Finally the arbitrary offset write occurs through a second fragment that only needs to be crafted to write data in the hole pointed to by the previously controlled hole metadata (`next_hole`) from the first packet. ### Recommendation Handle cases where `len` is strictly lower than 8 by preventing the overwrite of the hole metadata during the memcpy of the fragment. This could be achieved by either: * Moving the location where the hole metadata is stored when `len` is lower than `8`. * Or outright rejecting fragmented IP datagram with a Total Length (`ip_len`) lower than 28 bytes which is the minimum valid fragmented IP datagram size (as defined as the minimum fragment of 8 octets in the IP Specification Document: [RFC791](https://datatracker.ietf.org/doc/html/rfc791) page 25). ----------BUG 2---------- In compiled versions of U-Boot that define CONFIG_IP_DEFRAG, a value of `ip->ip_len` (IP packet header's Total Length) lower than `IP_HDR_SIZE` will lead to a negative value for `len` which will ultimately result in a buffer overflow during the subsequent `memcpy` that uses `len` as it's `count` parameter. This bug is only exploitable on local ethernet as it requires crafting an invalid packet to include an unexpected `ip_len` value in the IP UDP header that's lower than the minimum accepted Total Length of a packet (21 as defined in the IP Specification Document: [RFC791](https://datatracker.ietf.org/doc/html/rfc791)). Such packet would in all likelihood be dropped while being routed to its final destination through most routing equipment and as such requires the attacker to be in a local position in order to be exploited. ```C static struct ip_udp_hdr *__net_defragment(struct ip_udp_hdr *ip, int *lenp) { static uchar pkt_buff[IP_PKTSIZE] __aligned(PKTALIGN); static u16 first_hole, total_len; struct hole *payload, *thisfrag, *h, *newh; struct ip_udp_hdr *localip = (struct ip_udp_hdr *)pkt_buff; uchar *indata = (uchar *)ip; int offset8, start, len, done = 0; u16 ip_off = ntohs(ip->ip_off); /* payload starts after IP header, this fragment is in there */ payload = (struct hole *)(pkt_buff + IP_HDR_SIZE); offset8 = (ip_off & IP_OFFS); thisfrag = payload + offset8; start = offset8 * 8; len = ntohs(ip->ip_len) - IP_HDR_SIZE; ``` The last line of the previous excerpt from `u-boot/net/net.c` shows where the underflow to a negative `len` value occurs if `ip_len` is set to a value strictly lower than 20 (`IP_HDR_SIZE` being 20). Also note that in the above excerpt the `pkt_buff` buffer has a size of `CONFIG_NET_MAXDEFRAG` which defaults to 16 KB but can range from 1KB to 64 KB depending on configurations. ```C /* finally copy this fragment and possibly return whole packet */ memcpy((uchar *)thisfrag, indata + IP_HDR_SIZE, len); ``` In the above excerpt the `memcpy` overflows the destination by attempting to make a copy of nearly 4 gigabytes in a buffer that's designed to hold `CONFIG_NET_MAXDEFRAG` bytes at most which leads to a DoS. ### Recommendation Stop processing of the packet if `ip_len` is lower than 21 (as defined by the minimum length of a data carrying datagram in the IP Specification Document: [RFC791](https://datatracker.ietf.org/doc/html/rfc791) page 34)." Add a check for ip_len being less than 21 and stop processing the packet in this case. Such a check covers the two reported bugs. Reported-by: Nicolas Bidron <nicolas.bidron(a)nccgroup.com> Suggested-by: Nicolas Bidron <nicolas.bidron(a)nccgroup.com> Signed-off-by: Fabio Estevam <festevam(a)denx.de> --- Changes since v2: - Check ip_len against 21 (IP_MIN_TOTAL_LENGTH). include/net.h | 2 ++ net/net.c | 3 +++ 2 files changed, 5 insertions(+) diff --git a/include/net.h b/include/net.h index 675bf4171b17..8933b976fa07 100644 --- a/include/net.h +++ b/include/net.h @@ -391,6 +391,8 @@ struct ip_hdr { #define IP_HDR_SIZE (sizeof(struct ip_hdr)) +#define IP_MIN_TOTAL_LENGTH (IP_HDR_SIZE + 1) + /* * Internet Protocol (IP) + UDP header. */ diff --git a/net/net.c b/net/net.c index 034a5d6e67c0..81905f631592 100644 --- a/net/net.c +++ b/net/net.c @@ -907,6 +907,9 @@ static struct ip_udp_hdr *__net_defragment(struct ip_udp_hdr *ip, int *lenp) int offset8, start, len, done = 0; u16 ip_off = ntohs(ip->ip_off); + if (ip->ip_len < IP_MIN_TOTAL_LENGTH) + return NULL; + /* payload starts after IP header, this fragment is in there */ payload = (struct hole *)(pkt_buff + IP_HDR_SIZE); offset8 = (ip_off & IP_OFFS); -- 2.25.1

2 2

[GIT PULL] xilinx patches for v2022.07-rc4
by Michal Simek 26 May '22

26 May '22

Hi Tom, please pull these patches to your tree. All of them are fixes I have collected for v2022.07 version. Gitlab CI doesn't show any issue too. Thanks, Michal The following changes since commit c387e62614713d0cc9e3ed022b86c9f320b02853: Merge branch '2022-05-11-Kconfig-cleanups-etc' (2022-05-11 13:27:44 -0400) are available in the Git repository at: git@source.denx.de:u-boot/custodians/u-boot-microblaze.git tags/xilinx-for-v2022.07-rc4 for you to fetch changes up to 594f692f491f0def6c4b6543e158a7f367b35dcc: xilinx: zynqmp: Wire tee for Multi DTB use cases (2022-05-24 08:44:24 +0200) ---------------------------------------------------------------- Xilinx changes for v2022.07-rc4 zynqmp: - Fix DP PLL configuration for zcu102/zcu106 and SOM - Fix split mode for starting R5s - DT fixes - Remove firmware node for mini configurations - Wire TEE for multi DTB fit image xilinx: - Handle board_get_usable_ram_top(0) properly phy: - Extend psgtr timeout mmc: - Fix mini configuration which misses zynqmp_pm_is_function_supported() ---------------------------------------------------------------- Amit Kumar Mahapatra (1): arm64: zynqmp: Set qspi tx-buswidth to 4 Ashok Reddy Soma (1): phy: zynqmp: Increase timeout value to 10ms Jorge Ramirez-Ortiz (1): soc: xilinx: versal: fix out of bounds array access Michal Simek (11): soc: xilinx: zynqmp: fix out of bounds array access xilinx: Handle board_get_usable_ram_top(0) properly xilinx: zynqmp: Do not guard SPL_FS_LOAD_PAYLOAD_NAME by SDHCI driver arm64: zynqmp: Add gpio labels for modepin arm64: zynqmp: Fix opp-table-cpu arm64: zynqmp: Add power domain description for PL arm64: zynqmp: Add dmas, gpu, rtc, watchdogs and opp nodes for SOM arm64: zynqmp: Add PHY description for SGMII on vck190 SC arm64: zynqmp: Add linux,code for fwuen button arm64: zynqmp: Add DT description for si5328 for zcu102/zcu106 xilinx: zynqmp: Wire tee for Multi DTB use cases Neal Frager (5): arm64: zynqmp: zynqmp-zcu106-rev1.0: Fix DP PLL configuration arm64: zynqmp: zynqmp-zcu106-revA: Fix DP PLL configuration arm64: zynqmp: zynqmp-zcu102-revA: Fix DP PLL configuration arm64: zynqmp: Fix split mode reset functionality arm64: zynqmp: zynqmp-sm-k26-revA: Fix DP PLL configuration Piyush Mehta (1): arm64: zynqmp: Add mode-pin GPIO controller DT node T Karthik Reddy (3): Revert "arm64: xilinx: Set CONFIG_ZYNQMP_FIRMWARE config for mini emmc" mmc: zynq_sdhci: Add weak function prototype Revert "arm64: zynqmp: Add zynqmp firmware specific DT nodes" Vishal Patel (1): arm64: zynqmp: Add pwm-fan node and fix ttc0 pwm-cells property arch/arm/dts/zynqmp-e-a2197-00-revA.dts | 15 +++ arch/arm/dts/zynqmp-m-a2197-01-revA.dts | 2 +- arch/arm/dts/zynqmp-m-a2197-02-revA.dts | 2 +- arch/arm/dts/zynqmp-m-a2197-03-revA.dts | 2 +- arch/arm/dts/zynqmp-mini-emmc0.dts | 40 ------- arch/arm/dts/zynqmp-mini-emmc1.dts | 40 ------- arch/arm/dts/zynqmp-mini-qspi.dts | 2 +- arch/arm/dts/zynqmp-sm-k26-revA.dts | 115 +++++++++++++++++++- arch/arm/dts/zynqmp-topic-miamimp-xilinx-xdp-v1r1.dts | 2 +- arch/arm/dts/zynqmp-zc1232-revA.dts | 2 +- arch/arm/dts/zynqmp-zc1254-revA.dts | 2 +- arch/arm/dts/zynqmp-zc1751-xm015-dc1.dts | 2 +- arch/arm/dts/zynqmp-zc1751-xm018-dc4.dts | 2 +- arch/arm/dts/zynqmp-zcu102-revA.dts | 23 +++- arch/arm/dts/zynqmp-zcu104-revA.dts | 2 +- arch/arm/dts/zynqmp-zcu104-revC.dts | 2 +- arch/arm/dts/zynqmp-zcu106-revA.dts | 23 +++- arch/arm/dts/zynqmp-zcu111-revA.dts | 2 +- arch/arm/dts/zynqmp-zcu1275-revA.dts | 2 +- arch/arm/dts/zynqmp-zcu208-revA.dts | 2 +- arch/arm/dts/zynqmp-zcu216-revA.dts | 2 +- arch/arm/dts/zynqmp.dtsi | 11 +- arch/arm/mach-zynqmp/mkimage_fit_atf.sh | 10 ++ arch/arm/mach-zynqmp/mp.c | 31 +++++- board/xilinx/versal/board.c | 3 + board/xilinx/zynqmp/zynqmp-sm-k26-revA/psu_init_gpl.c | 3 + board/xilinx/zynqmp/zynqmp-zcu102-revA/psu_init_gpl.c | 4 +- board/xilinx/zynqmp/zynqmp-zcu106-rev1.0/psu_init_gpl.c | 4 +- board/xilinx/zynqmp/zynqmp-zcu106-revA/psu_init_gpl.c | 4 +- board/xilinx/zynqmp/zynqmp.c | 3 + configs/xilinx_versal_mini_emmc0_defconfig | 1 - configs/xilinx_versal_mini_emmc1_defconfig | 1 - configs/xilinx_zynqmp_mini_emmc0_defconfig | 1 - configs/xilinx_zynqmp_mini_emmc1_defconfig | 1 - drivers/mmc/zynq_sdhci.c | 5 + drivers/phy/phy-zynqmp.c | 2 +- drivers/soc/soc_xilinx_versal.c | 2 +- drivers/soc/soc_xilinx_zynqmp.c | 2 +- include/configs/xilinx_zynqmp.h | 2 - 39 files changed, 254 insertions(+), 122 deletions(-) -- Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91 w: www.monstr.eu p: +42-0-721842854 Maintainer of Linux kernel - Xilinx Microblaze Maintainer of Linux kernel - Xilinx Zynq ARM and ZynqMP ARM64 SoCs U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP/Versal SoCs

2 1

Pull request for efi-2022-07-rc4
by Heinrich Schuchardt 26 May '22

26 May '22

Dear Tom, The following changes since commit 7e0edcadb09d55d5319fdc862041fd1b874476f5: Merge branch 'master' of https://source.denx.de/u-boot/custodians/u-boot-sunxi (2022-05-24 23:29:00 -0400) are available in the Git repository at: https://source.denx.de/u-boot/custodians/u-boot-efi.git tags/efi-2022-07-rc4 for you to fetch changes up to 019ba3a6a644cceba46d92d42a1ed0677885a929: doc/build/gcc: add more required packages (2022-05-26 10:15:58 +0200) Gitlab CI showed no problems: https://source.denx.de/u-boot/custodians/u-boot-efi/-/pipelines/12127 ---------------------------------------------------------------- Pull request for efi-2022-07-rc4 UEFI: * fix a problem in loading an image from a short-path * fix building the bootmenu command for CONFIG_EFI_LOADER=n * correct the bootefi command syntax * add firmware management protocol to the documentation Others: * bootmenu: fix bootmenu title handling ---------------------------------------------------------------- AKASHI Takahiro (2): efi_loader: disk: add efi_disk_is_removable() efi_loader: bootmgr: fix a problem in loading an image from a short-path Bin Meng (2): doc: sandbox: Correct the memory size config option doc: sandbox: Add a note of disabling LTO when using gdb Heinrich Schuchardt (6): disk: incorrect message in is_gpt_valid() test: restore timeout after bootmenu unit test test: fix pylint warnings in test_efi_selftest.py test: don't change console timeout in EFI selftest. cmd/bootefi: correct command syntax doc/build/gcc: add more required packages Masahisa Kojima (2): bootmenu: fix bootmenu title handling lib/charset: fix compile warnings Vincent Stehlé (2): efi: fix documentation warnings doc/efi: add firmware management protocol to the documentation cmd/bootefi.c | 21 +++++--- cmd/bootmenu.c | 48 +++++++++++------ disk/part_efi.c | 4 +- doc/api/efi.rst | 6 +++ doc/arch/sandbox.rst | 5 +- doc/build/gcc.rst | 8 +-- doc/usage/cmd/bootefi.rst | 8 +-- include/charset.h | 2 +- include/efi_loader.h | 3 ++ lib/efi_loader/efi_bootmgr.c | 107 +++++++++++++++++++++++++++++++++++-- lib/efi_loader/efi_disk.c | 27 ++++++++++ lib/efi_loader/efi_firmware.c | 10 ++-- test/py/tests/test_bootmenu.py | 66 +++++++++++------------ test/py/tests/test_efi_selftest.py | 91 ++++++++++--------------------- 14 files changed, 266 insertions(+), 140 deletions(-)

3 2

[PATCH] net: Check for the minimum IP fragmented datagram size
by Fabio Estevam 26 May '22

26 May '22

From: Fabio Estevam <festevam(a)denx.de> Nicolas Bidron and Nicolas Guigo reported the two bugs below: " ----------BUG 1---------- In compiled versions of U-Boot that define CONFIG_IP_DEFRAG, a value of `ip->ip_len` (IP packet header's Total Length) higher than `IP_HDR_SIZE` and strictly lower than `IP_HDR_SIZE+8` will lead to a value for `len` comprised between `0` and `7`. This will ultimately result in a truncated division by `8` resulting value of `0` forcing the hole metadata and fragment to point to the same location. The subsequent memcopy will overwrite the hole metadata with the fragment data. Through a second fragment, this can be exploited to write to an arbitrary offset controlled by that overwritten hole metadata value. This bug is only exploitable locally as it requires crafting two packets the first of which would most likely be dropped through routing due to its unexpectedly low Total Length. However, this bug can potentially be exploited to root linux based embedded devices locally. ```C static struct ip_udp_hdr *__net_defragment(struct ip_udp_hdr *ip, int *lenp) { static uchar pkt_buff[IP_PKTSIZE] __aligned(PKTALIGN); static u16 first_hole, total_len; struct hole *payload, *thisfrag, *h, *newh; struct ip_udp_hdr *localip = (struct ip_udp_hdr *)pkt_buff; uchar *indata = (uchar *)ip; int offset8, start, len, done = 0; u16 ip_off = ntohs(ip->ip_off); /* payload starts after IP header, this fragment is in there */ payload = (struct hole *)(pkt_buff + IP_HDR_SIZE); offset8 = (ip_off & IP_OFFS); thisfrag = payload + offset8; start = offset8 * 8; len = ntohs(ip->ip_len) - IP_HDR_SIZE; ``` The last line of the previous excerpt from `u-boot/net/net.c` shows how the attacker can control the value of `len` to be strictly lower than `8` by issuing a packet with `ip_len` between `21` and `27` (`IP_HDR_SIZE` has a value of `20`). Also note that `offset8` here is `0` which leads to `thisfrag = payload`. ```C } else if (h >= thisfrag) { /* overlaps with initial part of the hole: move this hole */ newh = thisfrag + (len / 8); *newh = *h; h = newh; if (h->next_hole) payload[h->next_hole].prev_hole = (h - payload); if (h->prev_hole) payload[h->prev_hole].next_hole = (h - payload); else first_hole = (h - payload); } else { ``` Lower down the same function, execution reaches the above code path. Here, `len / 8` evaluates to `0` leading to `newh = thisfrag`. Also note that `first_hole` here is `0` since `h` and `payload` point to the same location. ```C /* finally copy this fragment and possibly return whole packet */ memcpy((uchar *)thisfrag, indata + IP_HDR_SIZE, len); ``` Finally, in the above excerpt the `memcpy` overwrites the hole metadata since `thisfrag` and `h` both point to the same location. The hole metadata is effectively overwritten with arbitrary data from the fragmented IP packet data. If `len` was crafted to be `6`, `last_byte`, `next_hole`, and `prev_hole` of the `first_hole` can be controlled by the attacker. Finally the arbitrary offset write occurs through a second fragment that only needs to be crafted to write data in the hole pointed to by the previously controlled hole metadata (`next_hole`) from the first packet. ### Recommendation Handle cases where `len` is strictly lower than 8 by preventing the overwrite of the hole metadata during the memcpy of the fragment. This could be achieved by either: * Moving the location where the hole metadata is stored when `len` is lower than `8`. * Or outright rejecting fragmented IP datagram with a Total Length (`ip_len`) lower than 28 bytes which is the minimum valid fragmented IP datagram size (as defined as the minimum fragment of 8 octets in the IP Specification Document: [RFC791](https://datatracker.ietf.org/doc/html/rfc791) page 25). ----------BUG 2---------- In compiled versions of U-Boot that define CONFIG_IP_DEFRAG, a value of `ip->ip_len` (IP packet header's Total Length) lower than `IP_HDR_SIZE` will lead to a negative value for `len` which will ultimately result in a buffer overflow during the subsequent `memcpy` that uses `len` as it's `count` parameter. This bug is only exploitable on local ethernet as it requires crafting an invalid packet to include an unexpected `ip_len` value in the IP UDP header that's lower than the minimum accepted Total Length of a packet (21 as defined in the IP Specification Document: [RFC791](https://datatracker.ietf.org/doc/html/rfc791)). Such packet would in all likelihood be dropped while being routed to its final destination through most routing equipment and as such requires the attacker to be in a local position in order to be exploited. ```C static struct ip_udp_hdr *__net_defragment(struct ip_udp_hdr *ip, int *lenp) { static uchar pkt_buff[IP_PKTSIZE] __aligned(PKTALIGN); static u16 first_hole, total_len; struct hole *payload, *thisfrag, *h, *newh; struct ip_udp_hdr *localip = (struct ip_udp_hdr *)pkt_buff; uchar *indata = (uchar *)ip; int offset8, start, len, done = 0; u16 ip_off = ntohs(ip->ip_off); /* payload starts after IP header, this fragment is in there */ payload = (struct hole *)(pkt_buff + IP_HDR_SIZE); offset8 = (ip_off & IP_OFFS); thisfrag = payload + offset8; start = offset8 * 8; len = ntohs(ip->ip_len) - IP_HDR_SIZE; ``` The last line of the previous excerpt from `u-boot/net/net.c` shows where the underflow to a negative `len` value occurs if `ip_len` is set to a value strictly lower than 20 (`IP_HDR_SIZE` being 20). Also note that in the above excerpt the `pkt_buff` buffer has a size of `CONFIG_NET_MAXDEFRAG` which defaults to 16 KB but can range from 1KB to 64 KB depending on configurations. ```C /* finally copy this fragment and possibly return whole packet */ memcpy((uchar *)thisfrag, indata + IP_HDR_SIZE, len); ``` In the above excerpt the `memcpy` overflows the destination by attempting to make a copy of nearly 4 gigabytes in a buffer that's designed to hold `CONFIG_NET_MAXDEFRAG` bytes at most which leads to a DoS. ### Recommendation Stop processing of the packet if `ip_len` is lower than 21 (as defined by the minimum length of a data carrying datagram in the IP Specification Document: [RFC791](https://datatracker.ietf.org/doc/html/rfc791) page 34)." Add a check for ip_len lesser than 28 and stop processing the packet in this case. Such a check covers the two reported bugs. Reported-by: Nicolas Bidron <nicolas.bidron(a)nccgroup.com> Signed-off-by: Fabio Estevam <festevam(a)denx.de> --- include/net.h | 2 ++ net/net.c | 3 +++ 2 files changed, 5 insertions(+) diff --git a/include/net.h b/include/net.h index 675bf4171b17..8933b976fa07 100644 --- a/include/net.h +++ b/include/net.h @@ -391,6 +391,8 @@ struct ip_hdr { #define IP_HDR_SIZE (sizeof(struct ip_hdr)) +#define IP_MIN_FRAG_DATAGRAM_SIZE 28 + /* * Internet Protocol (IP) + UDP header. */ diff --git a/net/net.c b/net/net.c index 034a5d6e67c0..81905f631592 100644 --- a/net/net.c +++ b/net/net.c @@ -907,6 +907,9 @@ static struct ip_udp_hdr *__net_defragment(struct ip_udp_hdr *ip, int *lenp) int offset8, start, len, done = 0; u16 ip_off = ntohs(ip->ip_off); + if (ip->ip_len < IP_MIN_FRAG_DATAGRAM_SIZE) + return NULL; + /* payload starts after IP header, this fragment is in there */ payload = (struct hole *)(pkt_buff + IP_HDR_SIZE); offset8 = (ip_off & IP_OFFS); -- 2.25.1

1 0

[PATCH] powerpc: bootm: Fix sizes in memory adjusting warning
by Pali Rohár 26 May '22

26 May '22

Old size is stored in size variable and new size is in bootm_size variable. Signed-off-by: Pali Rohár <pali(a)kernel.org> --- arch/powerpc/lib/bootm.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/arch/powerpc/lib/bootm.c b/arch/powerpc/lib/bootm.c index 8d65047aa4d4..2704f6562803 100644 --- a/arch/powerpc/lib/bootm.c +++ b/arch/powerpc/lib/bootm.c @@ -137,7 +137,8 @@ void arch_lmb_reserve(struct lmb *lmb) if (size < bootm_size) { ulong base = bootmap_base + size; - printf("WARNING: adjusting available memory to %lx\n", size); + printf("WARNING: adjusting available memory from 0x%lx to 0x%llx\n", + size, (unsigned long long)bootm_size); lmb_reserve(lmb, base, bootm_size - size); } -- 2.20.1

1 0

Vulnerability Disclosure in net/
by Nicolas Bidron 26 May '22

26 May '22

Hello, We found a couple of bugs in net/net.s in the IP defragmentation function __net_defragment(). Below the writeup for the 2 bugs: -----------BUG 1----------- # Hole Descriptor Overwrite in U-Boot IP Packet Defragmentation Leads to Arbitrary Out of Bounds Write Primitive (CVE-TBD) | | | | --- | --- | |Project | U-Boot | |Project URL | https://github.com/u-boot/u-boot | |Versions affected | all versions up to commit TBD | |Systems affected | All systems defining `CONFIG_IP_DEFRAG` | |CVE identifier | TBD | |Advisory URL | TBD | |Risk | Critical 9.6 (CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H) | |Authors | Nicolas Guigo, Nicolas Bidron | ### Summary U-boot is a popular boot loader for embedded systems with implementations for a large number of architectures and prominent in most linux based embedded systems. ### Location In `u-boot/net/net.c` the `__net_defragment` function line 900 through 1018. ### Impact The U-Boot implementation of [RFC815](https://datatracker.ietf.org/doc/html/rfc815) IP DATAGRAM REASSEMBLY ALGORITHMS is susceptible to a Hole Descriptor overwrite attack which ultimately leads to an arbitrary write primitve. ### Description In compiled versions of U-Boot that define CONFIG_IP_DEFRAG, a value of `ip->ip_len` (IP packet header's Total Length) higher than `IP_HDR_SIZE` and strictly lower than `IP_HDR_SIZE+8` will lead to a value for `len` comprised between `0` and `7`. This will ultimately result in a truncated division by `8` resulting value of `0` forcing the hole metadata and fragment to point to the same location. The subsequent memcopy will overwrite the hole metadata with the fragment data. Through a second fragment, this can be exploited to write to an arbitrary offset controlled by that overwritten hole metadata value. This bug is only exploitable locally as it requires crafting two packets the first of which would most likely be dropped through routing due to its unexpectedly low Total Length. However, this bug can potentially be exploited to root linux based embedded devices locally. ```C static struct ip_udp_hdr *__net_defragment(struct ip_udp_hdr *ip, int *lenp) { static uchar pkt_buff[IP_PKTSIZE] __aligned(PKTALIGN); static u16 first_hole, total_len; struct hole *payload, *thisfrag, *h, *newh; struct ip_udp_hdr *localip = (struct ip_udp_hdr *)pkt_buff; uchar *indata = (uchar *)ip; int offset8, start, len, done = 0; u16 ip_off = ntohs(ip->ip_off); /* payload starts after IP header, this fragment is in there */ payload = (struct hole *)(pkt_buff + IP_HDR_SIZE); offset8 = (ip_off & IP_OFFS); thisfrag = payload + offset8; start = offset8 * 8; len = ntohs(ip->ip_len) - IP_HDR_SIZE; ``` The last line of the previous excerpt from `u-boot/net/net.c` shows how the attacker can control the value of `len` to be strictly lower than `8` by issuing a packet with `ip_len` between `21` and `27` (`IP_HDR_SIZE` has a value of `20`). Also note that `offset8` here is `0` which leads to `thisfrag = payload`. ```C } else if (h >= thisfrag) { /* overlaps with initial part of the hole: move this hole */ newh = thisfrag + (len / 8); *newh = *h; h = newh; if (h->next_hole) payload[h->next_hole].prev_hole = (h - payload); if (h->prev_hole) payload[h->prev_hole].next_hole = (h - payload); else first_hole = (h - payload); } else { ``` Lower down the same function, execution reaches the above code path. Here, `len / 8` evaluates to `0` leading to `newh = thisfrag`. Also note that `first_hole` here is `0` since `h` and `payload` point to the same location. ```C /* finally copy this fragment and possibly return whole packet */ memcpy((uchar *)thisfrag, indata + IP_HDR_SIZE, len); ``` Finally, in the above excerpt the `memcpy` overwrites the hole metadata since `thisfrag` and `h` both point to the same location. The hole metadata is effectively overwritten with arbitrary data from the fragmented IP packet data. If `len` was crafted to be `6`, `last_byte`, `next_hole`, and `prev_hole` of the `first_hole` can be controlled by the attacker. Finally the arbitrary offset write occurs through a second fragment that only needs to be crafted to write data in the hole pointed to by the previously controlled hole metadata (`next_hole`) from the first packet. ### Recommendation Handle cases where `len` is strictly lower than 8 by preventing the overwrite of the hole metadata during the memcpy of the fragment. This could be achieved by either: * Moving the location where the hole metadata is stored when `len` is lower than `8`. * Or outright rejecting fragmented IP datagram with a Total Length (`ip_len`) lower than 28 bytes which is the minimum valid fragmented IP datagram size (as defined as the minimum fragment of 8 octets in the IP Specification Document: [RFC791](https://datatracker.ietf.org/doc/html/rfc791) page 25). ----------BUG 2---------- # Large buffer overflow leads to DoS in U-Boot IP Packet Defragmentation Code (CVE-TBD) | | | | --- | --- | |Project | U-Boot | |Project URL | https://github.com/u-boot/u-boot | |Versions affected | all versions up to commit TBD | |Systems affected | All systems defining `CONFIG_IP_DEFRAG` | |CVE identifier | TBD | |Advisory URL | TBD | |Risk | High 7.1 (CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:H) | |Authors | Nicolas Guigo, Nicolas Bidron | ### Summary U-boot is a popular boot loader for embedded systems with implementations for a large number of architectures and prominent in most linux based embedded systems. ### Location `u-boot/net/net.c` lines 915 and 1011. ### Impact The U-Boot implementation of [RFC815](https://datatracker.ietf.org/doc/html/rfc815) IP DATAGRAM REASSEMBLY ALGORITHMS is susceptible to a buffer overflow through a specially crafted fragmented IP Datagram with an invalid Total Length which creates Denial of Service conditions. ### Description In compiled versions of U-Boot that define CONFIG_IP_DEFRAG, a value of `ip->ip_len` (IP packet header's Total Length) lower than `IP_HDR_SIZE` will lead to a negative value for `len` which will ultimately result in a buffer overflow during the subsequent `memcpy` that uses `len` as it's `count` parameter. This bug is only exploitable on local ethernet as it requires crafting an invalid packet to include an unexpected `ip_len` value in the IP UDP header that's lower than the minimum accepted Total Length of a packet (21 as defined in the IP Specification Document: [RFC791](https://datatracker.ietf.org/doc/html/rfc791)). Such packet would in all likelihood be dropped while being routed to its final destination through most routing equipment and as such requires the attacker to be in a local position in order to be exploited. ```C static struct ip_udp_hdr *__net_defragment(struct ip_udp_hdr *ip, int *lenp) { static uchar pkt_buff[IP_PKTSIZE] __aligned(PKTALIGN); static u16 first_hole, total_len; struct hole *payload, *thisfrag, *h, *newh; struct ip_udp_hdr *localip = (struct ip_udp_hdr *)pkt_buff; uchar *indata = (uchar *)ip; int offset8, start, len, done = 0; u16 ip_off = ntohs(ip->ip_off); /* payload starts after IP header, this fragment is in there */ payload = (struct hole *)(pkt_buff + IP_HDR_SIZE); offset8 = (ip_off & IP_OFFS); thisfrag = payload + offset8; start = offset8 * 8; len = ntohs(ip->ip_len) - IP_HDR_SIZE; ``` The last line of the previous excerpt from `u-boot/net/net.c` shows where the undeflow to a negative `len` value occurs if `ip_len` is set to a value strictly lower than 20 (`IP_HDR_SIZE` being 20). Also note that in the above excerpt the `pkt_buff` buffer has a size of `CONFIG_NET_MAXDEFRAG` which defaults to 16 KB but can range from 1KB to 64 KB depending on configurations. ```C /* finally copy this fragment and possibly return whole packet */ memcpy((uchar *)thisfrag, indata + IP_HDR_SIZE, len); ``` In the above excerpt the `memcpy` overflows the destination by attempting to make a copy of nearly 4 gigabytes in a buffer that's designed to hold `CONFIG_NET_MAXDEFRAG` bytes at most which leads to a DoS. ### Recommendation Stop processing of the packet if `ip_len` is lower than 21 (as defined by the minimum length of a data carrying datagram in the IP Specification Document: [RFC791](https://datatracker.ietf.org/doc/html/rfc791) page 34). Nicolas Bidron, Nicolas Guigo

5 4

[PATCH 1/3] riscv: sifive: unmatched: Adjust for big ramdisk image
by Bin Meng 26 May '22

26 May '22

Move kernel_comp_addr_r to an address that comes before the ramdisk image, since the decompressed kernel size is known to us. This way we can allow big ramdisk image to be loaded. Signed-off-by: Bin Meng <bmeng.cn(a)gmail.com> --- include/configs/sifive-unmatched.h | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/include/configs/sifive-unmatched.h b/include/configs/sifive-unmatched.h index 087764666b..fa734a66be 100644 --- a/include/configs/sifive-unmatched.h +++ b/include/configs/sifive-unmatched.h @@ -56,12 +56,12 @@ #define CONFIG_EXTRA_ENV_SETTINGS \ "kernel_addr_r=0x84000000\0" \ - "fdt_addr_r=0x88000000\0" \ - "scriptaddr=0x88100000\0" \ - "pxefile_addr_r=0x88200000\0" \ - "ramdisk_addr_r=0x88300000\0" \ - "kernel_comp_addr_r=0x90000000\0" \ + "kernel_comp_addr_r=0x88000000\0" \ "kernel_comp_size=0x4000000\0" \ + "fdt_addr_r=0x8c000000\0" \ + "scriptaddr=0x8c100000\0" \ + "pxefile_addr_r=0x8c200000\0" \ + "ramdisk_addr_r=0x8c300000\0" \ "type_guid_gpt_loader1=" TYPE_GUID_LOADER1 "\0" \ "type_guid_gpt_loader2=" TYPE_GUID_LOADER2 "\0" \ "type_guid_gpt_system=" TYPE_GUID_SYSTEM "\0" \ -- 2.34.1

2 5

[PATCH 1/1] doc/build/gcc: add more required packages
by Heinrich Schuchardt 26 May '22

26 May '22

The following Python packages are used by U-Boot, too: * python3-asteval * python3-subunit * python3-testtools Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt(a)canonical.com> --- doc/build/gcc.rst | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/doc/build/gcc.rst b/doc/build/gcc.rst index 470a7aa349..682051abeb 100644 --- a/doc/build/gcc.rst +++ b/doc/build/gcc.rst @@ -27,10 +27,10 @@ Depending on the build targets further packages maybe needed device-tree-compiler dfu-util efitools flex gdisk graphviz imagemagick \ liblz4-tool libgnutls28-dev libguestfs-tools libncurses-dev \ libpython3-dev libsdl2-dev libssl-dev lz4 lzma lzma-alone openssl \ - pkg-config python3 python3-coverage python3-pkg-resources \ - python3-pycryptodome python3-pyelftools python3-pytest \ - python3-sphinxcontrib.apidoc python3-sphinx-rtd-theme python3-virtualenv \ - swig + pkg-config python3 python3-asteval python3-coverage \ + python3-pkg-resources python3-pycryptodome python3-pyelftools \ + python3-pytest python3-sphinxcontrib.apidoc python3-sphinx-rtd-theme \ + python3-subunit python3-testtools python3-virtualenv swig SUSE based ~~~~~~~~~~ -- 2.36.1

1 0

[PATCH] doc: sandbox: Add a note of disabling LTO when using gdb
by Bin Meng 26 May '22

26 May '22

Image created by LTO is not friendly to debugger, let's document this. Signed-off-by: Bin Meng <bmeng.cn(a)gmail.com> --- doc/arch/sandbox.rst | 2 ++ 1 file changed, 2 insertions(+) diff --git a/doc/arch/sandbox.rst b/doc/arch/sandbox.rst index 246ab5b380..19167d22fb 100644 --- a/doc/arch/sandbox.rst +++ b/doc/arch/sandbox.rst @@ -477,6 +477,8 @@ board_init_f() and board_init_r(). This approach can be used on normal boards as well as sandbox. +When debugging with gdb, it's better to disable Link Timer Optimizations +(CONFIG_LTO = n). SDL_CONFIG ---------- -- 2.25.1

2 1