fdt_region: Check for a single root node of the correct name

At present fdt_find_regions() assumes that the FIT is a valid devicetree.
If the FIT has two root nodes this is currently not detected in this
function, nor does libfdt's fdt_check_full() notice. Also it is possible
for the root node to have a name even though it should not.

Add checks for these and return -FDT_ERR_BADSTRUCTURE if a problem is
detected.

CVE-2021-27097

Signed-off-by: Simon Glass <sjg@chromium.org>
Reported-by: Bruce Monroe <bruce.monroe@intel.com>
Reported-by: Arie Haenel <arie.haenel@intel.com>
Reported-by: Julien Lenoir <julien.lenoir@intel.com>
Reviewed-By: Daniel Leidert <dleidert@debian.org>
Origin: https://github.com/u-boot/u-boot/commit/8a7d4cf9820ea16fabd25a6379351b4dc291204b
Bug: https://github.com/advisories/GHSA-3w66-96j7-fmcp
Bug-Debian: https://bugs.debian.org/983270
Bug-Debian-Security: https://security-tracker.debian.org/tracker/CVE-2021-27097
Bug-Freexian-Security: https://deb.freexian.com/extended-lts/tracker/CVE-2021-27097

Gbp-Pq: Name CVE-2021-27097-1.patch

squashfs: Fix heap corruption in sqfs_search_dir()

res needs to be large enough to store both strings rem and target,
plus the path separator and the terminator.
Currently the space for the path separator is not accounted, so
the heap is corrupted by one byte.

Signed-off-by: Richard Weinberger <richard@nod.at>
Reviewed-by: Miquel Raynal <miquel.raynal@bootlin.com>
Reviewed-By: Daniel Leidert <dleidert@debian.org>
Origin: https://source.denx.de/u-boot/u-boot/-/commit/048d795bb5b3d9c5701b4855f5e74bcf6849bf5e
Bug: https://www.openwall.com/lists/oss-security/2025/02/17/2
Bug-Debian: https://bugs.debian.org/1098254
Bug-Debian-Security: https://security-tracker.debian.org/tracker/CVE-2024-57259
Bug-Freexian-Security: https://deb.freexian.com/extended-lts/tracker/CVE-2024-57259

Gbp-Pq: Name CVE-2024-57259.patch

x86: Fix ptrdiff_t for x86_64

sbrk() assumes ptrdiff_t is large enough to enlarge/shrink the heap
by LONG_MIN/LONG_MAX.
So, use the long type, also to match the rest of the Linux ecosystem.

Signed-off-by: Richard Weinberger <richard@nod.at>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-By: Daniel Leidert <dleidert@debian.org>
Origin: https://source.denx.de/u-boot/u-boot/-/commit/c17b2a05dd50a3ba437e6373093a0d6a359cdee0
Bug: https://www.openwall.com/lists/oss-security/2025/02/17/2
Bug-Debian: https://bugs.debian.org/1098254
Bug-Debian-Security: https://security-tracker.debian.org/tracker/CVE-2024-57258
Bug-Freexian-Security: https://deb.freexian.com/extended-lts/tracker/CVE-2024-57258

Gbp-Pq: Name CVE-2024-57258-3.patch

dlmalloc: Fix integer overflow in request2size()

req is of type size_t, casting it to long opens the door
for an integer overflow.
Values between LONG_MAX - (SIZE_SZ + MALLOC_ALIGN_MASK) - 1 and LONG_MAX
cause and overflow such that request2size() returns MINSIZE.

Fix by removing the cast.
The origin of the cast is unclear, it's in u-boot and ppcboot since ever
and predates the CVS history.
Doug Lea's original dlmalloc implementation also doesn't have it.

Signed-off-by: Richard Weinberger <richard@nod.at>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-By: Daniel Leidert <dleidert@debian.org>
Origin: https://source.denx.de/u-boot/u-boot/-/commit/8642b2178d2c4002c99a0b69a845a48f2ae2706f
Bug: https://www.openwall.com/lists/oss-security/2025/02/17/2
Bug-Debian: https://bugs.debian.org/1098254
Bug-Debian-Security: https://security-tracker.debian.org/tracker/CVE-2024-57258
Bug-Freexian-Security: https://deb.freexian.com/extended-lts/tracker/CVE-2024-57258

Gbp-Pq: Name CVE-2024-57258-2.patch

dlmalloc: Fix integer overflow in sbrk()

Make sure that the new break is within mem_malloc_start
and mem_malloc_end before making progress.
ulong new = old + increment; can overflow for extremely large
increment values and memset() can get wrongly called.

Signed-off-by: Richard Weinberger <richard@nod.at>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-By: Daniel Leidert <dleidert@debian.org>
Origin: https://source.denx.de/u-boot/u-boot/-/commit/0a10b49206a29b4aa2f80233a3e53ca0466bb0b3
Bug: https://www.openwall.com/lists/oss-security/2025/02/17/2
Bug-Debian: https://bugs.debian.org/1098254
Bug-Debian-Security: https://security-tracker.debian.org/tracker/CVE-2024-57258
Bug-Freexian-Security: https://deb.freexian.com/extended-lts/tracker/CVE-2024-57258

Gbp-Pq: Name CVE-2024-57258-1.patch

[PATCH] squashfs: Fix stack overflow while symlink resolving

The squashfs driver blindly follows symlinks, and calls sqfs_size()
recursively. So an attacker can create a crafted filesystem and with
a deep enough nesting level a stack overflow can be achieved.

Fix by limiting the nesting level to 8.

Signed-off-by: Richard Weinberger <richard@nod.at>
Reviewed-by: Miquel Raynal <miquel.raynal@bootlin.com>
Reviewed-By: Daniel Leidert <dleidert@debian.org>
Origin: https://source.denx.de/u-boot/u-boot/-/commit/4f5cc096bfd0a591f8a11e86999e3d90a9484c34
Bug: https://www.openwall.com/lists/oss-security/2025/02/17/2
Bug-Debian: https://bugs.debian.org/1098254
Bug-Debian-Security: https://security-tracker.debian.org/tracker/CVE-2024-57257
Bug-Freexian-Security: https://deb.freexian.com/extended-lts/tracker/CVE-2024-57257

Gbp-Pq: Name CVE-2024-57257.patch

[PATCH] ext4: Fix integer overflow in ext4fs_read_symlink()

While zalloc() takes a size_t type, adding 1 to the le32 variable
will overflow.
A carefully crafted ext4 filesystem can exhibit an inode size of 0xffffffff
and as consequence zalloc() will do a zero allocation.

Later in the function the inode size is again used for copying data.
So an attacker can overwrite memory.

Avoid the overflow by using the __builtin_add_overflow() helper.

Signed-off-by: Richard Weinberger <richard@nod.at>
Reviewed-By: Daniel Leidert <dleidert@debian.org>
Origin: https://source.denx.de/u-boot/u-boot/-/commit/35f75d2a46e5859138c83a75cd2f4141c5479ab9
Bug: https://www.openwall.com/lists/oss-security/2025/02/17/2
Bug-Debian: https://bugs.debian.org/1098254
Bug-Debian-Security: https://security-tracker.debian.org/tracker/CVE-2024-57256
Bug-Freexian-Security: https://deb.freexian.com/extended-lts/tracker/CVE-2024-57256

Gbp-Pq: Name CVE-2024-57256.patch

squashfs: Fix integer overflow in sqfs_resolve_symlink()

A carefully crafted squashfs filesystem can exhibit an inode size of 0xffffffff,
as a consequence malloc() will do a zero allocation.
Later in the function the inode size is again used for copying data.
So an attacker can overwrite memory.
Avoid the overflow by using the __builtin_add_overflow() helper.

Signed-off-by: Richard Weinberger <richard@nod.at>
Reviewed-by: Miquel Raynal <miquel.raynal@bootlin.com>
Reviewed-By: Daniel Leidert <dleidert@debian.org>
Origin: https://source.denx.de/u-boot/u-boot/-/commit/233945eba63e24061dffeeaeb7cd6fe985278356
Bug: https://www.openwall.com/lists/oss-security/2025/02/17/2
Bug-Debian: https://bugs.debian.org/1098254
Bug-Debian-Security: https://security-tracker.debian.org/tracker/CVE-2024-57255
Bug-Freexian-Security: https://deb.freexian.com/extended-lts/tracker/CVE-2024-57255

Gbp-Pq: Name CVE-2024-57255.patch

squashfs: Fix integer overflow in sqfs_inode_size()

A carefully crafted squashfs filesystem can exhibit an extremly large
inode size and overflow the calculation in sqfs_inode_size().
As a consequence, the squashfs driver will read from wrong locations.

Fix by using __builtin_add_overflow() to detect the overflow.

Signed-off-by: Richard Weinberger <richard@nod.at>
Reviewed-by: Miquel Raynal <miquel.raynal@bootlin.com>
Reviewed-By: Daniel Leidert <dleidert@debian.org>
Origin: https://source.denx.de/u-boot/u-boot/-/commit/c8e929e5758999933f9e905049ef2bf3fe6b140d
Bug: https://www.openwall.com/lists/oss-security/2025/02/17/2
Bug-Debian: https://bugs.debian.org/1098254
Bug-Debian-Security: https://security-tracker.debian.org/tracker/CVE-2024-57254
Bug-Freexian-Security: https://deb.freexian.com/extended-lts/tracker/CVE-2024-57254

Gbp-Pq: Name CVE-2024-57254.patch

[PATCH] usb: gadget: dfu: Fix the unchecked length field

DFU implementation does not bound the length field in USB
DFU download setup packets, and it does not verify that
the transfer direction. Fixing the length and transfer
direction.

CVE-2022-2347

Signed-off-by: Venkatesh Yadav Abbarapu <venkatesh.abbarapu@amd.com>
Reviewed-by: Marek Vasut <marex@denx.de>
Note (<dleidert>: I'm not sure if this patch should be applied as well:
https://source.denx.de/u-boot/u-boot/-/commit/86b6a38863bebb70a65a53f93a1ffafc4a472169

It is not related to the issue, though.

Reviewed-By: Daniel Leidert <dleidert@debian.org>
Origin: https://source.denx.de/u-boot/u-boot/-/commit/fbce985e28eaca3af82afecc11961aadaf971a7e
Bug: https://www.openwall.com/lists/oss-security/2022/07/08/2
Bug-Debian: https://bugs.debian.org/1014959
Bug-Debian-Security: https://security-tracker.debian.org/tracker/CVE-2022-2347
Bug-Freexian-Security: https://deb.freexian.com/extended-lts/tracker/CVE-2022-2347

Gbp-Pq: Name CVE-2022-2347.patch

net: nfs: Fix CVE-2022-30767 (old CVE-2019-14196)

This patch mitigates the vulnerability identified via CVE-2019-14196.

The previous patch was bypassed/ineffective, and now the vulnerability
is identified via CVE-2022-30767. The patch removes the sanity check
introduced to mitigate CVE-2019-14196 since it's ineffective.
filefh3_length is changed to unsigned type integer, preventing negative
numbers from being used during comparison with positive values during
size sanity checks.

Signed-off-by: Andrea zi0Black Cappa <zi0Black@protonmail.com>
Reviewed-By: Daniel Leidert <dleidert@debian.org>
Origin: https://source.denx.de/u-boot/u-boot/-/commit/bdbf7a05e26f3c5fd437c99e2755ffde186ddc80
Bug: https://lists.denx.de/pipermail/u-boot/2022-May/483952.htmll
Bug-Debian: https://bugs.debian.org/1014471
Bug-Debian-Security: https://security-tracker.debian.org/tracker/CVE-2022-30767
Bug-Freexian-Security: https://deb.freexian.com/extended-lts/tracker/CVE-2022-30767

Gbp-Pq: Name CVE-2022-30767.patch

net: Check for the minimum IP fragmented datagram size

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@nccgroup.com>
Signed-off-by: Fabio Estevam <festevam@denx.de>
Reviewed-By: Daniel Leidert <dleidert@debian.org>
Origin: https://source.denx.de/u-boot/u-boot/-/commit/b85d130ea0cac152c21ec38ac9417b31d41b5552
Bug: https://www.nccgroup.com/us/research-blog/technical-advisory-multiple-vulnerabilities-in-u-boot-cve-2022-30790-cve-2022-30552/
Bug-Debian: https://bugs.debian.org/1014470
Bug-Debian-Security: https://security-tracker.debian.org/tracker/CVE-2022-30790
Bug-Debian-Security: https://security-tracker.debian.org/tracker/CVE-2022-30552
Bug-Freexian-Security: https://deb.freexian.com/extended-lts/tracker/CVE-2022-30790
Bug-Freexian-Security: https://deb.freexian.com/extended-lts/tracker/CVE-2022-30552

Gbp-Pq: Name CVE-2022-30790.patch

[PATCH] fs/squashfs: sqfs_read: Prevent arbitrary code execution

Following Jincheng's report, an out-of-band write leading to arbitrary
code execution is possible because on one side the squashfs logic
accepts directory names up to 65535 bytes (u16), while U-Boot fs logic
accepts directory names up to 255 bytes long.

Prevent such an exploit from happening by capping directory name sizes
to 255. Use a define for this purpose so that developers can link the
limitation to its source and eventually kill it some day by dynamically
allocating this array (if ever desired).

Link: https://lore.kernel.org/all/CALO=DHFB+yBoXxVr5KcsK0iFdg+e7ywko4-e+72kjbcS8JBfPw@mail.gmail.com
Reported-by: Jincheng Wang <jc.w4ng@gmail.com>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Tested-by: Jincheng Wang <jc.w4ng@gmail.com>
Reviewed-By: Daniel Leidert <dleidert@debian.org>
Origin: https://source.denx.de/u-boot/u-boot/-/commit/2ac0baab4aff1a0b45067d0b62f00c15f4e86856
Bug: https://lore.kernel.org/all/CALO=DHFB+yBoXxVr5KcsK0iFdg+e7ywko4-e+72kjbcS8JBfPw@mail.gmail.com/
Bug-Debian: https://bugs.debian.org/1014528
Bug-Debian-Security: https://security-tracker.debian.org/tracker/CVE-2022-33103
Bug-Freexian-Security: https://deb.freexian.com/extended-lts/tracker/CVE-2022-33103

Gbp-Pq: Name CVE-2022-33103.patch

[PATCH] fs/squashfs: Use kcalloc when relevant

A crafted squashfs image could embed a huge number of empty metadata
blocks in order to make the amount of malloc()'d memory overflow and be
much smaller than expected. Because of this flaw, any random code
positioned at the right location in the squashfs image could be memcpy'd
from the squashfs structures into U-Boot code location while trying to
access the rearmost blocks, before being executed.

In order to prevent this vulnerability from being exploited in eg. a
secure boot environment, let's add a check over the amount of data
that is going to be allocated. Such a check could look like:

if (!elem_size || n > SIZE_MAX / elem_size)
        return NULL;

The right way to do it would be to enhance the calloc() implementation
but this is quite an impacting change for such a small fix. Another
solution would be to add the check before the malloc call in the
squashfs implementation, but this does not look right. So for now, let's
use the kcalloc() compatibility function from Linux, which has this
check.

Fixes: c5100613037 ("fs/squashfs: new filesystem")
Reported-by: Tatsuhiko Yasumatsu <Tatsuhiko.Yasumatsu@sony.com>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Tested-by: Tatsuhiko Yasumatsu <Tatsuhiko.Yasumatsu@sony.com>
Reviewed-By: Daniel Leidert <dleidert@debian.org>
Origin: https://github.com/u-boot/u-boot/commit/b6f4c757959f8850e1299a77c8e5713da78e8ec0
Bug: https://lists.denx.de/pipermail/u-boot/2022-June/487467.html
Bug-Debian-Security: https://security-tracker.debian.org/tracker/CVE-2022-33967
Bug-Freexian-Security: https://deb.freexian.com/extended-lts/tracker/CVE-2022-33967

Gbp-Pq: Name CVE-2022-33967.patch

[PATCH] i2c: fix stack buffer overflow vulnerability in i2c md command

When running "i2c md 0 0 80000100", the function do_i2c_md parses the
length into an unsigned int variable named length. The value is then
moved to a signed variable:

    int nbytes = length;
    #define DISP_LINE_LEN 16
    int linebytes = (nbytes > DISP_LINE_LEN) ? DISP_LINE_LEN : nbytes;
    ret = dm_i2c_read(dev, addr, linebuf, linebytes);

On systems where integers are 32 bits wide, 0x80000100 is a negative
value to "nbytes > DISP_LINE_LEN" is false and linebytes gets assigned
0x80000100 instead of 16.

The consequence is that the function which reads from the i2c device
(dm_i2c_read or i2c_read) is called with a 16-byte stack buffer to fill
but with a size parameter which is too large. In some cases, this could
trigger a crash. But with some i2c drivers, such as drivers/i2c/nx_i2c.c
(used with "nexell,s5pxx18-i2c" bus), the size is actually truncated to
a 16-bit integer. This is because function i2c_transfer expects an
unsigned short length. In such a case, an attacker who can control the
response of an i2c device can overwrite the return address of a function
and execute arbitrary code through Return-Oriented Programming.

Fix this issue by using unsigned integers types in do_i2c_md. While at
it, make also alen unsigned, as signed sizes can cause vulnerabilities
when people forgot to check that they can be negative.

Signed-off-by: Nicolas Iooss <nicolas.iooss+uboot@ledger.fr>
Reviewed-by: Heiko Schocher <hs@denx.de>
Reviewed-By: Daniel Leidert <dleidert@debian.org>
Origin: https://source.denx.de/u-boot/u-boot/-/commit/8f8c04bf1ebbd2f72f1643e7ad9617dafa6e5409
Bug: https://lists.denx.de/pipermail/u-boot/2022-June/486113.html
Bug-Debian: https://bugs.debian.org/1014529
Bug-Debian-Security: https://security-tracker.debian.org/tracker/CVE-2022-34835
Bug-Freexian-Security: https://deb.freexian.com/extended-lts/tracker/CVE-2022-34835

Gbp-Pq: Name CVE-2022-34835.patch

[PATCH] efi_loader: switch to non-secure mode later

Some ARMv7 boards using PSCI require to be in secure-mode when booted via
'bootz' or 'bootm'. During distro-boot 'bootefi bootmgr' is called to check
if booting via UEFI is possible.

With the change we change the switch from secure mode to non-secure mode is
moved from the UEFI subsystem setup to just before calling StartImage().

Cc: Jernej Škrabec <jernej.skrabec@gmail.com>
Reported by: Andre Przywara <andre.przywara@arm.com>
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Gbp-Pq: Topic upstream
Gbp-Pq: Name 0001-efi_loader-switch-to-non-secure-mode-later.patch

[PATCH] configs: add PineTab defconfig

From 2c346cacb4b0841051bceb27a57058020860ab8b Mon Sep 17 00:00:00 2001
Forwarded: https://patchwork.ozlabs.org/project/uboot/list/?series=232582

The PineTab device-tree is already in u-boot, this commit adds the corresponding
defconfig, based on pinephone_defconfig.

Signed-off-by: Arnaud Ferraris <arnaud.ferraris@collabora.com>
Gbp-Pq: Topic pinetab
Gbp-Pq: Name 0001-configs-add-PineTab-defconfig.patch

disable-preboot

Disable USE_PREBOOT as a workaround to boot failure triggered by
initializing USB. (Closes: #973323, #980434)

Reported upstream:

  https://lists.denx.de/pipermail/u-boot/2021-January/438098.html

Gbp-Pq: Topic rk3399
Gbp-Pq: Name disable-preboot

bootz_and_raw_initrd

Enable booting of zImage/vmlinuz and initrd without requiring the use
of mkimage to create uImage/uInitrd.

Gbp-Pq: Topic n900
Gbp-Pq: Name bootz_and_raw_initrd.patch

[PATCH] qemu-riscv64_smode, sifive-fu540: fix extlinux (define preboot)

From 3fc056f0b9f7c26e58a1e947c8c0184e55919614 Mon Sep 17 00:00:00 2001
Forwarded: https://patchwork.ozlabs.org/patch/1151125/

Commit 37304aaf60bf92a5dc3ef222ba520698bd862a44 removed preboot
commands in RISC-V targets and broke extlinux support as reported
by Fu Wei <wefu@redhat.com>.

The patch finishes migration of CONFIG_USE_PREBOOT and CONFIG_REBOOT
to Kconfig.

Signed-off-by: David Abdurachmanov <david.abdurachmanov@sifive.com>
Gbp-Pq: Topic riscv64
Gbp-Pq: Name qemu-riscv64_smode-sifive-fu540-fix-extlinux-define-.patch

[PATCH] arm: config: fix default console only to specify the device

This reverts commit 767edf0f6b3eaa0303f3fd6afdc14ddce0aca70c and restores
commit 232ed3ca534708527a9515c7c41bc3542949525c.

Debian's flash-kernel expect the console variable to just contain the device,
because it will set the bootargs to "console=${console}". So revert adding
"console=" to the console parameter, but also adjust the shipped bootscripts
for exynos boards to cope with it.

Bug-Debian: https://bugs.debian.org/920116
Signed-off-by: Benjamin Drung <bdrung@debian.org>
Gbp-Pq: Topic exynos
Gbp-Pq: Name 0001-arm-config-fix-default-console-only-to-specify-the-d.patch

test-imagetools-test-fixes

This patch allows testing in an alternate directory and also detects
failures to execute commands, treating that as a failure.

Gbp-Pq: Name test-imagetools-test-fixes

omap5_distro_bootcmd

Enable distro_bootcmd support (doc/README.distro) for omap5 targets.

Gbp-Pq: Topic am57xx
Gbp-Pq: Name omap5_distro_bootcmd

ensure-config-sandbox-for-make-env

Ensure that CONFIG_SANDBOX is set when running "make env", avoiding a
failure to build caused by config_distro_bootcmd.h following the wrong
codepath...

Gbp-Pq: Name ensure-config-sandbox-for-make-env.patch

Add spl/arndale-spl.bin rule

Gbp-Pq: Topic arndale
Gbp-Pq: Name board-spl-rule.diff

mx53loco

Enables support for ext4, the "load" command, and using bootz with raw initrds.

Gbp-Pq: Name mx53loco

Enable generic tools build

Gbp-Pq: Name tools-generic-builds.patch

add-debian-revision-to-u-boot-version

Add the debian revision to the U-boot version, which is displayed at
boot and can be helpful to determine which specific version is used.

Gbp-Pq: Name add-debian-revision-to-u-boot-version

u-boot (2021.01+dfsg-5+deb11u2) bullseye-security; urgency=medium

  * Non-maintainer upload by the Debian LTS team.
  * d/patches/CVE-2021-27097-1.patch, d/patches/CVE-2021-27097-2.patch,
    d/patches/CVE-2021-27097-3.patch, d/patches/CVE-2021-27097-4.patch: Add
    patches to fix CVE-2021-27097.
    - Fix mishandling of a modified FIT (closes: #983270).
  * d/patches/CVE-2021-27138-1.patch, d/patches/CVE-2021-27138-2.patch: Add
    patches to fix CVE-2021-27138.
    - Fix mishandled use of unit addresses in a FIT (closes: #983269).

[dgit import unpatched u-boot 2021.01+dfsg-5+deb11u2]

Import u-boot_2021.01+dfsg-5+deb11u2.debian.tar.xz

[dgit import tarball u-boot 2021.01+dfsg-5+deb11u2 u-boot_2021.01+dfsg-5+deb11u2.debian.tar.xz]

Import u-boot_2021.01+dfsg.orig.tar.xz

[dgit import orig u-boot_2021.01+dfsg.orig.tar.xz]