Fix up the crashing address in cases where we're indirectly jumping to a non-canonical address on x86-64
gabrielesvelto opened this issue · comments
This is a follow-up to issue #749. If we're dealing with a ret instruction or an indirect call (e.g. call [rax+8], something which would be common when accessing a vtable) then the address won't be in a register but rather in the memory that's being fetched. For cases like ret we'll almost always have the address as it'll be on the stack. For calls it won't be as common to have the target memory area handy, but we can tweak the minidump writer to capture the areas pointed by the registers in the first frame - something we already do under certain conditions - to increase the probability of having access to the right object.
In particular this would be useful for detecting indirect calls into dead objects which will always result in a general protection fault, due to the contents of the object being filled with the poison pattern.
Here's a few crashes that exhibit this behavior:
The PR I opened seems to work pretty well on the crashes you linked (adding additional memory accesses, when memory is available, causing an adjusted address to be generated). 4e5e0370-1712-4510-9d5a-a37120230112 is a little odd, it adds an additional memory access (0xe0) but it doesn't result in an adjusted address. Though actually I guess it's my fault, as I don't add any logic for is_likely_null_pointer_dereference in the indirect addresses. I don't think in this case that would be likely (the stack memory or pointer is just wrong), so we probably need a new AdjustedAddress? Or are we happy with it not adjusting the address and just adding the additional memory access in this case?
Or are we happy with it not adjusting the address and just adding the additional memory access in this case?
I'd say this is fine, we don't want to handle every possible corner-case. I'll make a note about this and we'll fix it later.