1. 07 Jun, 2022 1 commit
    • Pali Rohár's avatar
      watchdog: Fix SPL build with watchdog disabled in asm files · 06ceff70
      Pali Rohár authored and Stefan Roese's avatar Stefan Roese committed
      Allow to compile assembler files in SPL build which calls WATCHDOG_RESET
      function when watchdog is disabled in SPL and enabled in U-Boot proper.
      
      This issue was fixed in past by commit 7fbd42f5
      
       ("watchdog: Handle SPL
      build with watchdog disabled") for C source files, but not for assembler
      source files.
      
      Currently the only assembler source file which calls WATCHDOG_RESET is
      arch/powerpc/lib/ticks.S, so this patch affects and fixes powerpc SPL
      builds.
      Signed-off-by: default avatarPali Rohár <pali@kernel.org>
      Reviewed-by: Stefan Roese's avatarStefan Roese <sr@denx.de>
      06ceff70
  2. 06 Jun, 2022 3 commits
  3. 04 Jun, 2022 6 commits
  4. 03 Jun, 2022 10 commits
    • Tom Rini's avatar
      Merge branch '2022-06-03-assorted-fixes' · 90189ecd
      Tom Rini authored
      - armv8 TCR write bugfix, ubifs bugfix, imx8mq clk bugfixes, two network
        fixes, Add U-Boot version to chosen node, update TI AM64x board
        maintainers
      90189ecd
    • Dave Gerlach's avatar
      board: ti: am64x: Update MAINTAINERS · c30f6d62
      Dave Gerlach authored and Tom Rini's avatar Tom Rini committed
      
      
      Move maintainership of TI AM64x boards to Vignesh.
      Signed-off-by: default avatarDave Gerlach <d-gerlach@ti.com>
      c30f6d62
    • Pali Rohár's avatar
      squashfs: Fix compilation on big endian systems · 9320db09
      Pali Rohár authored and Tom Rini's avatar Tom Rini committed
      
      Signed-off-by: default avatarPali Rohár <pali@kernel.org>
      Reviewed-by: default avatarMiquel Raynal <miquel.raynal@bootlin.com>
      9320db09
    • Peng Fan's avatar
      imx: imx8mq: select CONFIG_CMD_CLK · ad9f3771
      Peng Fan authored and Tom Rini's avatar Tom Rini committed
      
      
      select CONFIG_CMD_CLK to enable dump clk in uboot shell
      Signed-off-by: Peng Fan's avatarPeng Fan <peng.fan@nxp.com>
      ad9f3771
    • Peng Fan's avatar
      imx: imx8mq: default select CLK_IMX8MQ · 4230d68a
      Peng Fan authored and Tom Rini's avatar Tom Rini committed
      Since the power domain driver default select CONFIG_CLK, so we will
      meet lots failures without CLK_IMX8MQ, so default select it.
      
      Fixes: commit 4eb82c2e
      
       ("imx: power-domain: Get rid of SMCCC dependency")
      Signed-off-by: Peng Fan's avatarPeng Fan <peng.fan@nxp.com>
      4230d68a
    • Francesco Dolcini's avatar
      fdt: Add U-Boot version to chosen node · 622ecee9
      Francesco Dolcini authored and Tom Rini's avatar Tom Rini committed
      
      
      Add a new device tree property "u-boot,version" in the chosen node to
      pass the U-Boot version to the operating system.
      This can be useful to implement a firmware upgrade procedure from the
      operating system.
      Signed-off-by: default avatarFrancesco Dolcini <francesco.dolcini@toradex.com>
      Reviewed-by: Tom Rini's avatarTom Rini <trini@konsulko.com>
      622ecee9
    • Fabio Estevam's avatar
      net: Check for the minimum IP fragmented datagram size · b85d130e
      Fabio Estevam authored and Tom Rini's avatar Tom Rini committed
      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: default avatarNicolas Bidron <nicolas.bidron@nccgroup.com>
      Signed-off-by: Fabio Estevam's avatarFabio Estevam <festevam@denx.de>
      b85d130e
    • André Przywara's avatar
      armv8: Fix TCR 64-bit writes · 2b641211
      André Przywara authored and Tom Rini's avatar Tom Rini committed
      
      
      The AArch64 TCR_ELx register is a 64-bit register, and many newer
      architecture features use bits in the upper half. So far U-Boot was
      igorant of those bits, trying to leave them alone.
      However, in an effort to set bit 31 to 1, it failed doing so, because
      the compiler sign-extended "1 << 31", so that all bits[63:31] got set.
      
      Older ARMv8.0 cores don't define anything dangerous up there, but newer
      architecture revisions do, and setting all those bits will end badly:
      =================
      $ qemu-system-aarch64 -cpu max ....
      U-Boot 2022.07-rc1 (May 09 2022 - 15:21:00 +0100)
      
      DRAM:  1.5 GiB
      =================  (hangs here)
      
      Defining TCR_ELx_RSVD to "1U << 31" avoids the sign-extension, so all
      upper bits stay at a safe 0 value. This means no more surprises when
      U-Boot runs on a more capable CPU core.
      Reported-by: default avatarBalaji Anandapadmanaban <Balaji.Anandapadmanaban@arm.com>
      Signed-off-by: André Przywara's avatarAndre Przywara <andre.przywara@arm.com>
      Reviewed-by: Peng Fan's avatarPeng Fan <peng.fan@nxp.com>
      Tested-by: default avatarPeter Collingbourne <pcc@google.com>
      Reviewed-by: default avatarPeter Collingbourne <pcc@google.com>
      2b641211
    • Michael Walle's avatar
      net: enetc: unregister mdiobus · 7704b7fd
      Michael Walle authored and Tom Rini's avatar Tom Rini committed
      If the device fails to probe - for example, when there is no
      ethaddr set - then the private data is automatically freed
      but the mdiobus remains registered.
      
      Fixes: 1e354cb3
      
       ("drivers: net: fsl_enetc: register internal MDIO bus")
      Signed-off-by: default avatarMichael Walle <michael@walle.cc>
      7704b7fd
    • Pali Rohár's avatar
      ubifs: Fix lockup/crash when reading files · 339f6529
      Pali Rohár authored and Tom Rini's avatar Tom Rini committed
      Commit b1a14f8a ("UBIFS: Change ubifsload to not read beyond the
      requested size") added optimization to do not read more bytes than it is
      really needed. But this commit introduced incorrect handling of the hole at
      the end of file. This logic cause U-Boot to crash or lockup when trying to
      read from the ubifs filesystem.
      
      When read_block() call returns -ENOENT error (not an error, but the hole)
      then dn-> structure is not filled and contain garbage. So using of dn->size
      for memcpy() argument cause that U-Boot tries to copy unspecified amount of
      bytes from possible unmapped memory. Which randomly cause lockup of P2020
      CPU.
      
      Fix this issue by copying UBIFS_BLOCK_SIZE bytes from read buffer when
      dn->size is not available. UBIFS_BLOCK_SIZE is the size of the buffer
      itself and read_block() fills buffer by zeros when it returns -ENOENT.
      
      This patch fixes ubifsload on P2020.
      
      Fixes: b1a14f8a ("UBIFS: Change ubifsload to not read beyond the requested size")
      Signed-o...
      339f6529
  5. 31 May, 2022 2 commits
  6. 28 May, 2022 16 commits
  7. 27 May, 2022 2 commits