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? -- Tom
signature.asc
Description: PGP signature
