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.
