Comment # 18
on bug 10476
from Alex Kirk
> (In reply to Pascal Quantin from comment #17)
> (In reply to Alex Kirk from comment #16)
> > Bill was correct on both fronts. Landed now, and it was in fact Frame 412.
> >
> > Identical crash when running with "-C Default". I didn't think I had made
> > any config changes on that particular installation.
> >
> > As for that pointer - invalid as in NULL, or pointing off somewhere wonky in
> > memory? If the latter, my immediate thought would be to see if the value
> > retrieved looks like it came from that frame, because if that's the case,
> > it's most likely exploitable.
>
> Invalid as we get a non null but wrong pointer (not the address that we
> pushed in the TRY block (tshark.c:2092) at the very beginning of the
> dissection).
> To make things clear: it's not the dissection of the last frame on which
> tshark chokes, but on the ENDTRY block (tshark.c:2111) once dissection is
> complete.
You do realize that non-null pointers that are "wrong" are how arbitrary code
execution happens, right?
I've ready the TRY/ENDTRY block and I admit to not understanding where exactly
in the C the issue is occurring. Are we talking the Catch for the OutOfMemory
error, or is there some other thing implied in that block?
You are receiving this mail because:
- You are watching all bug changes.