Upstream actually has a patch for this issue already. They refactored that loop (and others) in a read_variable_length function at https://github.com/lz4/lz4/blob/dev/lib/lz4.c#L1630, which has a pre-loop check like the one I added.

Okay, sounds good!
 
> In terms of divergence, it seems like upstream changed quite a bit since it was pulled into coreboot. I considered pulling from upstream, but given that coreboot also made modifications to lz4.c.inc and that I'm fairly new to coreboot, I was a bit hesitant to generate a large patch. I can give it a shot if you'd like though.

I don't think(?) we made modifications (except for whitespace on a few lines) since I pulled it in, other than this one now. But I also pulled it from the tip of the development branch right after I upstreamed something myself, not sure how much of that made it back to master.

Since it works fine as is I'm a bit wary about making a big uprev. You can try if you want to, but we'd definitely need to check that performance didn't regress. We also need the inPlaceDecode thing, which I added upstream but the maintainer probably doesn't care too much about, so we'd need to make sure that's still there and is still checked for in all cases even where the code was refactored.

View Change

To view, visit change 39174. To unsubscribe, or for help writing mail filters, visit settings.