[perl #129027] null pointer deref Perl_mess_sv (util.c:1508)

a simpler way to patch this would be to add a protection on the PL_curcop

diff --git a/util.c b/util.c
index a69ddad..a1e44b4 100644
--- a/util.c
+++ b/util.c
@@ -1522,7 +1522,7 @@ Perl_mess_sv(pTHX_ SV *basemsg, bool consume)
        sv_copypv(sv, basemsg);
     }

-    if (!SvCUR(sv) || *(SvEND(sv) - 1) != '\n') {
+    if (PL_curcop && (!SvCUR(sv) || *(SvEND(sv) - 1) != '\n')) {
        /*
         * Try and find the file and line for PL_op.  This will usually be
         * PL_curcop, but it might be a cop that has been optimised away.  We

On Fri Aug 26 07:18:51 2016, public@khwilliamson.com wrote:
> On 08/25/2016 07:50 PM, riusksk via RT wrote:
> > 在2016-八月-25 07:16:34 星期四时，dcollinsn@gmail.com写到：
> >> This appears to be a very complicated duplicate of RT #129027. This
> >> one spews debug output for about 30 seconds, and it doesn't actually
> >> segfault for me.
> >>
> >> It's a null deref, the pointer is correctly zeroed and then
> >> incorrectly used (it's dereferencing 0x21 because that's the offset
> >> into the struct), so not a security bug. My patch in that ticket
> >> should also fix this, but I'm not sure because I can't actually repro.
> >
> >
> > ok,thx, close it.
> >
> > ---
> > via perlbug:  queue: perl5 status: open
> > https://rt.perl.org/Ticket/Display.html?id=129075
> >
> 
> Instead of closing it, I merged it into #129027.  You will then get 
> notified when that gets fixed, and if your issue isn't actually fixed by 
> that, this can be reopened.
> 




---
via perlbug:  queue: perl5 status: open
https://rt.perl.org/Ticket/Display.html?id=129027

• [perl #129027] null pointer deref Perl_mess_sv (util.c:1508) by Atoomic via RT