On Wed Jun 13, 2018 at 04:59:42PM -0400, Todd Mortimer wrote:
> 
> 
> > 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. 

I would prefer to commit the diff at least to fix crashes all qtwebkit
consumers. In the long term, we should replace qtwebkit with
qtwebengine. qtwebkit is no longer maintained.

> 
> 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?

Sure but I don't have the time.

> > 
> > 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. 
> 

Reply via email to