From: SCHNEIDER Johannes <johannes.schneider@leica-geosystems.com>
To: "barebox@lists.infradead.org" <barebox@lists.infradead.org>
Subject: Re: [PATCH] lib: decompress_unlz4: drop redundant -4 in wrapper call to unlz4
Date: Sat, 13 Jun 2026 09:37:54 +0000 [thread overview]
Message-ID: <AM0PR06MB414868E79F9E8C8128214B70BC192@AM0PR06MB4148.eurprd06.prod.outlook.com> (raw)
In-Reply-To: <20260613051225.3778935-1-johannes.schneider@leica-geosystems.com>
Hoi,
please disregard this patch :-S
i've since found out that the root cause lies in the way we build lz4 compressed fitimage parts - there a plain lz4 call, with no 4-byte size trailer is used. And this missing trailer is what triggered the "Error: Fit: data corrupted" - which is non fatal anyway, as the system still booted.
Now i'm wondering why barebox is using this (legacy?) format?
gruß
Johannes
________________________________________
From: Johannes Schneider <johannes.schneider@leica-geosystems.com>
Sent: Saturday, June 13, 2026 07:12
To: barebox@lists.infradead.org
Cc: SCHNEIDER Johannes
Subject: [PATCH] lib: decompress_unlz4: drop redundant -4 in wrapper call to unlz4
decompress_unlz4() passes in_len - 4 to unlz4(), as if the caller had
already stripped the LZ4 legacy frame magic from the buffer. But unlz4()
reads the magic itself from buf[0..3] and, in the buffer-input path,
explicitly accounts for it via:
if (!fill) {
inp += 4;
size -= 4;
}
So the magic is subtracted twice from the running size counter. After
the last chunk is consumed, the counter underflows to -4 instead of 0,
which trips the "data corrupted" check at the end of the chunk loop:
if (!fill) {
size -= chunksize;
if (size == 0)
break;
else if (size < 0) {
error("data corrupted");
goto exit_2;
}
inp += chunksize;
}
The bug is benign in practice — by the time the size check fires, all
chunks have already been successfully decompressed and flushed, and ret
holds the 0 returned by the last lz4_decompress_unknownoutputsize()
call. unlz4() returns 0 and the caller treats the operation as
successful, but a spurious "data corrupted" line is printed on every
LZ4 decompression. With pr_fmt set by image-fit.c, FIT-image kernel
boots show:
ERROR: FIT: data corrupted
right between the configuration line and the cmdline-append line.
Pass in_len through unchanged. unlz4() handles the magic itself in both
the input and fill paths.
Fill-mode callers (e.g. uncompress_fd_to_fd) are unaffected: they pass
in_len=0, and unlz4() overwrites the initial size on the first fill()
call.
Assisted-by: Claude:claude-opus-4-7
Signed-off-by: Johannes Schneider <johannes.schneider@leica-geosystems.com>
---
lib/decompress_unlz4.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/decompress_unlz4.c b/lib/decompress_unlz4.c
index 2bb30e71bb..17bb4e5de7 100644
--- a/lib/decompress_unlz4.c
+++ b/lib/decompress_unlz4.c
@@ -209,6 +209,6 @@ STATIC int decompress_unlz4(unsigned char *buf, long in_len,
void(*error)(char *x)
)
{
- return unlz4(buf, in_len - 4, fill, flush, output, posp, error);
+ return unlz4(buf, in_len, fill, flush, output, posp, error);
}
#define decompress decompress_unlz4
base-commit: 6c70fb327d486376c1f2e37dfff2212cb9eebb1b
--
2.43.0
next prev parent reply other threads:[~2026-06-13 9:52 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-13 5:12 Johannes Schneider
2026-06-13 9:37 ` SCHNEIDER Johannes [this message]
2026-06-15 10:00 ` Ahmad Fatoum
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=AM0PR06MB414868E79F9E8C8128214B70BC192@AM0PR06MB4148.eurprd06.prod.outlook.com \
--to=johannes.schneider@leica-geosystems.com \
--cc=barebox@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox