Fix potential segfault with stream iterators. #1923
Conversation
|
@evantypanski can you see if this fixes the issue from #1918? It's now raining an exception ( |
|
Sure I'll take a look on my reproducers tomorrow, I'll be driving for the rest of the day :) Thanks for looking at this, I figured it'd take me a little longer just to figure out the generated code |
|
@rsmmr this indeed fixes the use-after-free in the reproducers I have |
Great, thanks for confirming. Is it now reporting an exception ( |
I see no discernable difference end-to-end for cases that only had a UAF with the sanitizer but didn't segfault. The verbose logs are exactly the same and any logs that Zeek output are exactly the same in every case I tried. In other cases that did segfault, it's hard to track down that exact exception - they have lots of them anyway since they're trying to parse data that doesn't fit. so - maybe?
Well, I'll say that everything end-to-end seems to be as expected: cases that only saw UAF but no segfault work the same, then cases that saw a segfault no longer segfault. Cases that segfaulted also seem to have more of that exception in analyzer.log (compared to just removing the So - it's pretty tough for me to tell, but at least this doesn't seem to do anything bad and fixes the segfault so I see that as correct. If you have a specific test I can do that too. The HTTP examples in the issue seem to be representative of the problem |
That sounds good enough to me. I'll get this ready for review & merge then. Thanks! |
When trimming off the beginning of a stream, an existing iterator could end up dereferencing its internal chunk pointer even if the chunk now no longer existed. The issue was inside the increment/decrement operations, which didn't check if the *current* iterator offset was still valid (because only then the current chunk is guaranteed to be valid too). Closes #1918.
rsmmr
force-pushed
the
topic/robin/gh-1918-trim-fix
branch
from
3e703eb
to
e88650c
Compare
When trimming off the beginning of a stream, an existing iterator
could end up dereferencing its internal chunk pointer even if the
chunk now no longer existed. The issue was inside the
increment/decrement operations, which didn't check if the current
iterator offset was still valid (because only then the current chunk
is guaranteed to be valid too).
Closes #1918.