[PATCH v3] mkimage: Default to 8-byte alignment for DTBs added via -b argument

[Sean Anderson]

On 1/27/26 11:06, Tom Rini wrote:
> On Tue, Jan 27, 2026 at 01:36:59AM +0100, Marek Vasut wrote:
>> On 1/26/26 11:58 PM, Tom Rini wrote:
>>
>> > > > Some validation of "len" has to be done before it is fed into strcmp() here.
>> > >
>> > > Well if you are concerned about lacking a nul-terminator then we will
>> > > read at most 8 bytes beyond the string.
>>
>> Which is wrong, and trivial to fix -- check the "len" that is already
>> provided to you by fdt_getprop() and make sure it is exactly length of
>> FIT_TYPE_PROP before doing the strcmp() . Then you should be safe.
>>
>> > > The other thing that can go wrong is if we get something like
>> > > "flat_dt\0extra data" we will match.
>>
>> This I did not consider. So maybe what needs to be done is compare the
>> length and then memcmp() instead of strcmp().
>>
>> > > Surprisingly the closest we have to this construct is fdt_string_eq_. I
>> > > suppose this is because most strings in U-Boot are guaranteed to be
>> > > nul-terminated.
>>
>> fdt_string_eq_() seems like the best fit, yes , nice.
>
> Bad news, fdt_string_eq_() is an internal call in libfdt. Good news,
> fdt_getprop() makes use of it via its eventual call chain. Which I think
> gets back to what I said earlier, libfdt is doing the input sanitization
> for us, or so many other places are more useful to exploit?
>

No, the check in fdt_getprop is only for the name, not the value (which
could be arbitrary binary data including many nul bytes).

I think the assumption in most of U-Boot is that the provided FDT is
trusted (or at least not maliciously ill-formed).  functions like
image_get_checksum_algo read up to 6 bytes beyond full_name if full_name
== "". It's possible to read off the end of the DTB if this is the very
last string in the strings block and there is no trailing padding. If
we're really concerned about this (e.g. to avoid false-positives with
ASAN), then we should just add (say) 16 bytes to the end of every DTB
when we malloc it.

--Sean

[Embedded World 2026, SECO SpA]<https://www.messe-ticket.de/Nuernberg_SHOP/embeddedworld2026/Landing?code=ew26561753&returnUrl=%2FNuernberg_SHOP%2Fembeddedworld2026%2FProfile>