> On Jun 13, 2018, at 11:11, Theo de Raadt <[email protected]> wrote:
>
> Rafael Sadowski <[email protected]> wrote:
>
>> Switch off retguard in qtwebkit fix the crashes above.
>>
>> Please find below a diff to disbale retguard for qtwebkit and respect
>> CC/CXX in Qt.
>
> This diff misses the point. The problem should be looked at a little
> deeper.
>
> retguard is a stack-corruption detector. The return address isn't
> what is expected. This looks like an interface where JIT and non-JIT
> code touch, perhaps by adjusting the return address on the stack without
> being aware it needs an XOR. Maybe the XOR cookie be discovered by
> XOR'ing the previous return value if that is known, to re-apply it to
> the new ret value.
If this is indeed an instance of the return address being deliberately modified
between function entry and exit then that will be hard to fix so the program
can update the cookie on stack so the check passes. In this case the easiest
thing to do is disable retguard as this diff does. Chromium doesn’t have this
problem though, but maybe earlier versions of webkit did this and qtwebkit is
based on those.
If this is the cookie value being corrupted then that would indicate a bug in
the program that is being triggered by the stack frame being adjusted to make
space for the retguard cookie.
I don’t know how hard it is to attach a debugger to this and see if the return
address is being modified or if the cookie is being corrupted.
>
> Aren't you a little curious?
>
> Also -- with your diff, is the old -fstack-protector(-strong) enabled
> or disabled? I think it is disabled.
Disabling retguard does not disable the stack protector, so whatever stack
protector is enabled by the usual makefile will continue to apply.
