fix out-of-bounds read in find.cc
#300
Conversation
libcxx hardening was breaking in kati's tests, since `TrimLeftSpace(cur_)` may return an empty string_view, and we're unconditionally accessing `[0]` after that. It looks like the code that follows the `while` loop gracefully handles empty strings, so add a simple check for `empty()` that falls through to that. Test: Android: `prebuilts/build-tools/build-prebuilts.sh` now passes
|
Some of the kati unittests failed on my machine on If not, happy to pull docker on a personal machine and iterate. |
|
/cc @colincross @Colecf |
danw
left a comment
There was a problem hiding this comment.
I'm slightly surprised you didn't run into an out-of-bounds read in expr.cc:ParseDollar too -- in order to properly parse things it reads past the end of the string view. I noticed that while working the rust implementation, which adds another boolean argument to that function (src-rs/expr.rs)
|
Thanks for the quick review & merge! Yeah, not sure why that wasn't hit, but the hardening check introduction is still pretty early stages. Maybe I'll bump into that in the coming weeks, as the presubmits turn a bit greener. :) |
libcxx hardening was breaking in kati's tests, since
TrimLeftSpace(cur_)may return an empty string_view, and we're unconditionally accessing[0]after that.It looks like the code that follows the
whileloop gracefully handles empty strings, so add a simple check forempty()that falls through to that.Test: Android:
prebuilts/build-tools/build-prebuilts.shnow passes