Skip Menu |

Preferred bug tracker

Please visit the preferred bug tracker to report your issue.

This queue is for tickets about the Perl-Core CPAN distribution.

Report information
The Basics
Id: 124722
Status: open
Priority: 0/
Queue: Perl-Core

People
Owner: Nobody in particular
Requestors: hackyzh002 [...] gmail.com
Cc:
AdminCc:

Bug Information
Severity: (no value)
Broken in: (no value)
Fixed in: (no value)



Subject: NULL pointer dereference in Perl_runops_standard
From: hackyzh002 [...] gmail.com
/perl-5.27.9/perl -le 'BEGIN{$SIG{__DIE__} =sub{exit(0)}}unshift' ==95151==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000000 (pc 0x000000abccbd bp 0x00000119cb28 sp 0x7ffdbda5a550 T0) #0 0xabccbc in Perl_pp_unshift /home/hackyzh/Desktop/perl-5.27.9/pp.c:5524 #1 0x92c74a in Perl_runops_standard /home/hackyzh/Desktop/perl-5.27.9/run.c:41 #2 0x555b39 in S_run_body /home/hackyzh/Desktop/perl-5.27.9/perl.c:2750 #3 0x555b39 in perl_run /home/hackyzh/Desktop/perl-5.27.9/perl.c:2671 #4 0x42b6e5 in main /home/hackyzh/Desktop/perl-5.27.9/perlmain.c:122 #5 0x7f29c157682f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2082f) #6 0x42c6c8 in _start (/home/hackyzh/Desktop/perl-5.27.9/perl+0x42c6c8) AddressSanitizer can not provide additional info. SUMMARY: AddressSanitizer: SEGV /home/hackyzh/Desktop/perl-5.27.9/pp.c:5524 Perl_pp_unshift ==95151==ABORTING
Subject: [perl #132953] AutoReply: Fwd: [rt.cpan.org #124722] NULL pointer dereference in Perl_runops_standard
Date: Thu, 08 Mar 2018 00:51:53 -0800
To: bug-Perl-Core [...] rt.cpan.org
From: perl5-security-report-followup [...] perl.org
Greetings, This message has been automatically generated in response to the creation of a perl security report regarding: "Fwd: [rt.cpan.org #124722] NULL pointer dereference in Perl_runops_standard". There is no need to reply to this message right now. Your ticket has been assigned an ID of [perl #132953]. Please include the string: [perl #132953] in the subject line of all future correspondence about this issue. To do so, you may reply to this message (please delete unnecessary quotes and text.) Thank you, perl5-security-report-followup@perl.org ------------------------------------------------------------------------- X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2018.3.8.84516 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2018.3.8.84516 Date: Thu, 8 Mar 2018 03:51:35 -0500 Message-ID: <20180308085136.0E6257D5@rtcpan.develooper.com> Received: from xx1.develooper.com (xx1.dev [10.0.100.115]) by rtperl.develooper.com (Postfix) with ESMTP id AEB6172D for <rt-perl5-security@rtperl.dev>; Thu, 8 Mar 2018 00:51:52 -0800 (PST) Received: from localhost (xx1.develooper.com [127.0.0.1]) by localhost (Postfix) with ESMTP id 52574120C46 for <rt-perl5-security@rtperl.dev>; Thu, 8 Mar 2018 00:51:52 -0800 (PST) Received: from xx1.develooper.com (xx1.develooper.com [127.0.0.1]) by localhost (Postfix) with SMTP id DAB0B120C39 for <rt-perl5-security@rtperl.dev>; Thu, 8 Mar 2018 00:51:50 -0800 (PST) Received: from x6.develooper.com (x6.develooper.com [207.171.7.86]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by xx1.develooper.com (Postfix) with ESMTPS id 96551120C46 for <rt-perl5-security@rt.perl.org>; Thu, 8 Mar 2018 00:51:50 -0800 (PST) Received: by x6.develooper.com (Postfix, from userid 514) id 14AF3FD2; Thu, 8 Mar 2018 00:51:50 -0800 (PST) Received: (qmail 3836 invoked from network); 8 Mar 2018 08:51:44 -0000 Received: from xx1.develooper.com (207.171.7.115) by x6.develooper.com with SMTP; 8 Mar 2018 08:51:44 -0000 Received: from localhost (xx1.develooper.com [127.0.0.1]) by localhost (Postfix) with ESMTP id F171E120CDD for <perlmail-perl5-security-report@onion.perl.org>; Thu, 8 Mar 2018 00:51:43 -0800 (PST) Received: from xx1.develooper.com (xx1.develooper.com [127.0.0.1]) by localhost (Postfix) with SMTP id 8AE44120CD5 for <perlmail-perl5-security-report@onion.perl.org>; Thu, 8 Mar 2018 00:51:42 -0800 (PST) Received: from rtcpan.develooper.com (rtcpan.develooper.com [207.171.7.181]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by xx1.develooper.com (Postfix) with ESMTPS id 1F5B1120C39 for <perl5-security-report@perl.org>; Thu, 8 Mar 2018 00:51:36 -0800 (PST) Received: by rtcpan.develooper.com (Postfix, from userid 536) id 0E6257D5; Thu, 8 Mar 2018 00:51:36 -0800 (PST) Subject: Fwd: [rt.cpan.org #124722] NULL pointer dereference in Perl_runops_standard To: perl5-security-report@perl.org Content-Type: multipart/mixed; boundary="----------=_1520499095-22341-1" X-Original-To: rt-perl5-security@rtperl.dev From perlmail@x6.develooper.com Thu Mar 8 00:51:52 2018 From: bug-Perl-Core@rt.cpan.org Delivered-To: rt-perl5-security@rtperl.dev Delivered-To: perlmail-perl5-security-report@onion.perl.org X-RT-Mail-Extension: perl5-security CC: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mx3.develooper.com Return-Path: <perlmail@x6.develooper.com> X-Spam-Status: No, score=-2.2 required=6.0 tests=ALL_TRUSTED,BAYES_00, MIME_HEADER_CTYPE_ONLY,T_TVD_MIME_NO_HEADERS,URIBL_BLOCKED autolearn=no version=3.3.1 X-RT-Interface: Email
Subject: Re: [perl #132953] Fwd: [rt.cpan.org #124722] NULL pointer dereference in Perl_runops_standard
Date: Thu, 08 Mar 2018 03:39:36 -0800
To: bug-Perl-Core [...] rt.cpan.org
From: "Dave Mitchell via RT" <perl5-security-report-followup [...] perl.org>
On Thu, Mar 08, 2018 at 12:51:53AM -0800, via RT wrote: Show quoted text
> # New Ticket Created by > # Please include the string: [perl #132953] > # in the subject line of all future correspondence about this issue. > # <URL: https://rt.perl.org/Ticket/Display.html?id=132953 > > > > > This is forward of transaction #1775448 of a ticket #124722
Show quoted text
> /perl-5.27.9/perl -le 'BEGIN{$SIG{__DIE__} =sub{exit(0)}}unshift'
The unshift is a syntax error, so compilation triggers the __DIE__ handler, which does an exit(0). This causes a longjmp back to perl_parse(), which sees a zero STATUS_EXIT and returns 0 (success). main() sees a successful return from perl_parse() and so continues with perl_run(), which then crashes on the badly-formed optree. I don't think its a security issue, as it involves feeding code with syntax errors into the parser. I'm not very confident about how to fix it though: the whole exit semantics is beyond my ken. In particular, in perl_parse() there is this: case 2: /* my_exit() was called */ ... pop stacks ... ret = STATUS_EXIT; if (ret == 0) { /* * At this point we should do * ret = 0x100; * to avoid [perl #2754], but that bugfix has been postponed * because of the Module::Install breakage it causes * [perl #132577]. */ } #2754 is: From a CHECK{}, you cannot exit(0) which had a fix from Zefram in Dec 2017, which was reverted because it broke Module::Install (and you can't get people to upgrade Module::Install) -- "Foul and greedy Dwarf - you have eaten the last candle." -- "Hordes of the Things", BBC Radio.
在2018-三月-08 06:39:44 星期四时,perl5-security-report-followup@perl.org写到: Show quoted text
> On Thu, Mar 08, 2018 at 12:51:53AM -0800, via RT wrote:
> > # New Ticket Created by > > # Please include the string: [perl #132953] > > # in the subject line of all future correspondence about this issue. > > # <URL: https://rt.perl.org/Ticket/Display.html?id=132953 > > > > > > > > > This is forward of transaction #1775448 of a ticket #124722
>
> > /perl-5.27.9/perl -le 'BEGIN{$SIG{__DIE__} =sub{exit(0)}}unshift'
> > The unshift is a syntax error, so compilation triggers the __DIE__ > handler, which does an exit(0). This causes a longjmp back to > perl_parse(), which sees a zero STATUS_EXIT and returns 0 (success). > main() sees a successful return from perl_parse() and so continues > with perl_run(), which then crashes on the badly-formed optree. > > I don't think its a security issue, as it involves feeding code with > syntax errors into the parser. > > I'm not very confident about how to fix it though: the whole exit > semantics is beyond my ken. > > In particular, in perl_parse() there is this: > > case 2: > /* my_exit() was called */ > ... pop stacks ... > ret = STATUS_EXIT; > if (ret == 0) { > /* > * At this point we should do > * ret = 0x100; > * to avoid [perl #2754], but that bugfix has been postponed > * because of the Module::Install breakage it causes > * [perl #132577]. > */ > } > > #2754 is: From a CHECK{}, you cannot exit(0) > > which had a fix from Zefram in Dec 2017, which was reverted because > it broke Module::Install (and you can't get people to upgrade > Module::Install) >
Isn't the null pointer dereference a security issue? It can cause denial of service.
Subject: [perl #132953] Fwd: [rt.cpan.org #124722] NULL pointer dereference in Perl_runops_standard
Date: Mon, 12 Mar 2018 16:10:16 -0700
To: bug-Perl-Core [...] rt.cpan.org
From: "Tony Cook via RT" <perlbug-followup [...] perl.org>
On Thu, 08 Mar 2018 03:39:36 -0800, davem wrote: Show quoted text
> On Thu, Mar 08, 2018 at 12:51:53AM -0800, via RT wrote:
> > # New Ticket Created by > > # Please include the string: [perl #132953] > > # in the subject line of all future correspondence about this issue. > > # <URL: https://rt.perl.org/Ticket/Display.html?id=132953 > > > > > > > > > This is forward of transaction #1775448 of a ticket #124722
>
> > /perl-5.27.9/perl -le 'BEGIN{$SIG{__DIE__} =sub{exit(0)}}unshift'
> > The unshift is a syntax error, so compilation triggers the __DIE__ > handler, which does an exit(0). This causes a longjmp back to > perl_parse(), which sees a zero STATUS_EXIT and returns 0 (success). > main() sees a successful return from perl_parse() and so continues > with perl_run(), which then crashes on the badly-formed optree. > > I don't think its a security issue, as it involves feeding code with > syntax errors into the parser.
I agree, now public. Tony
Subject: Re: [perl #132953] Fwd: [rt.cpan.org #124722] NULL pointer dereference in Perl_runops_standard
Date: Fri, 30 Mar 2018 16:25:18 -0700
To: bug-Perl-Core [...] rt.cpan.org
From: "Zefram via RT" <perlbug-followup [...] perl.org>
Dave Mitchell wrote: Show quoted text
>I'm not very confident about how to fix it though:
It *was* fixed in 5.27.7, as part of [perl #2754]. 5.27.7 doesn't crash on the test case for this ticket, but cleanly exits as requested. It was de-fixed in 5.27.8 due to CPAN breakage [perl #132577]. The current intent is to re-fix all of that in 5.29. -zefram