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

[Marek Vasut]

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.

> And gets back to my original point. Either we're fine here, because
> libfdt is doing enough input validation (type and len come from
> fdt_getprop(...)) and if that passes enough validation to happen but
> also allow malicious input this is not the most interesting place to
> wreck havoc. Or we're fine, actually. Which is what I was saying on IRC.
We are not fine, fdt_getprop() returns pointer to the string in DT and 
its length decoded from the DT, it doesn't validate any of it. But what 
Sean found, fdt_string_eq_(), seems like the right fit/fix here.