An integer overflow in nvlist size calculation could lead
to under-allocation and heap buffer overflow.

Signed-off-by: Timo tp Preißl <t.preissl@proton.me>
Reviewed-by: Simon Glass <simon.glass@canonical.com>
Reviewed-by: Tom Rini <trini@konsulko.com>

Drop all duplicate newlines. No functional change.

Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>

As part of bringing the master branch back in to next, we need to allow
for all of these changes to exist here.

Reported-by: Jonas Karlman <jonas@kwiboo.se>
Signed-off-by: Tom Rini <trini@konsulko.com>

Prepare v2024.07-rc3

When bringing in the series 'arm: dts: am62-beagleplay: Fix Beagleplay
Ethernet"' I failed to notice that b4 noticed it was based on next and
so took that as the base commit and merged that part of next to master.

This reverts commit c8ffd1356d42223cbb8c86280a083cc3c93e6426, reversing
changes made to 2ee6f3a5f7550de3599faef9704e166e5dcace35.

Reported-by: Jonas Karlman <jonas@kwiboo.se>
Signed-off-by: Tom Rini <trini@konsulko.com>

In order to prevent crashing due to infinite recursion and actually
decompress the requested data, call the zlib function 'uncompress'
instead.

Signed-off-by: WHR <msl0000023508@gmail.com>

Currently no features are implemented, only the zpool version 5000 that
indicating the features support, is recognized. Since it is possible for
OpenZFS to create a pool with features support enabled, but without
enabling any actual feature, this change enables U-Boot to read such
pools.

Signed-off-by: WHR <msl0000023508@gmail.com>

Remove <common.h> from all "fs/" files and when needed add
missing include files directly.

Signed-off-by: Tom Rini <trini@konsulko.com>

Without this patch, the while loop being modified goes on infinitely,
but with the patch I am able to boot linux on zfs on a jetson tx2 nx.

It seems like this code was never tested because the logic is clearly
wrong. The function do_div(a,b) does a division that modifies the first
parameter to have a = a / b, and returns the remainder of the division.
So clearly in the usual case when file->offset = 0, the line
"blkid = do_div(blkid, blksz);" just results in blkid being set to zero
on every iteration of the loop, rather than being incremented as blocks
are read. Hence the zeroth block is read over and over and this becomes
an infinite loop.

So instead capture the remainder of the division in a "blkoff" variable,
and use that to properly calculate the memory address to move from in
memmove() below.

For example, if file->offset were 1337, on the first iteration of the
loop blkid would be 0 and blkoff would be 1337. If the blksz is 131072
(as it was for me), that amount of data would be copied into
data->file_buf. movesize would be 131072 - 1337 = 129735 so 129735 bytes
would be moved into buf. On the second iteration of the loop (assuming
there is one), red would be 129735, blkid would be 1, blkoff would be 0,
and 131072 bytes would be copied into buf. And so on...

Signed-off-by: Phaedrus Leeds <mwleeds@mailtundra.com>

As evidenced by how other filesystems handle it, a return value of 0
from fs_devread() means failure; nonzero means success. The opposite
assumption was being made in zfs.c for the use of zfs_devread() so fix
the confusion by making zfs_devread() return 0 on success.

It probably doesn't make sense to change the handling of zfs_devread()
in zfs.c instead, because as it is it matches the semantics of the other
functions there.

Signed-off-by: Phaedrus Leeds <mwleeds@mailtundra.com>