heap-buffer-overflow (WRITE of size 8) in Perl_pp_reverse #16291
Comments
From @geeknikThis bug is triggered in Perl v5.27.6-156-g5d4548b73b compiled with Clang ./perl -e 'for$0(0..1000){()=(0..$0,scalar reverse)}' ==16254==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x619000000480 is located 0 bytes to the right of 1024-byte region previously allocated by thread T0 here: SUMMARY: AddressSanitizer: heap-buffer-overflow /root/perl/pp.c:5663:2 in |
From zefram@fysh.orgBrian Carpenter wrote:
Thanks. The stack reallocation logic in pp_reverse is faulty. I'm not sure about whether this should be a security ticket. I wouldn't -zefram |
From zefram@fysh.org0001-don-t-lose-mark-when-pp_reverse-extends-stack.patchFrom c9bfd95aa536fc56adcac57d5982ff324dd56979 Mon Sep 17 00:00:00 2001
From: Zefram <zefram@fysh.org>
Date: Fri, 8 Dec 2017 19:23:29 +0000
Subject: [PATCH] don't lose mark when pp_reverse extends stack
Nullary reverse needs to extend the stack to push its result scalar.
It was actually extending the stack, but doing so invalidated MARK,
which it relied upon to place the stack pointer afterwards. Upon stack
reallocation it was therefore leaving the stack pointer pointing to the
freed stack memory. Reformulate stack manipulation to not rely on MARK
after extending. Fixes [perl #132544].
---
pp.c | 13 +++++++------
t/op/reverse.t | 7 ++++++-
2 files changed, 13 insertions(+), 7 deletions(-)
diff --git a/pp.c b/pp.c
index 130019f..3bf04d1 100644
--- a/pp.c
+++ b/pp.c
@@ -5615,13 +5615,16 @@ PP(pp_reverse)
STRLEN len;
SvUTF8_off(TARG); /* decontaminate */
- if (SP - MARK > 1)
+ if (SP - MARK > 1) {
do_join(TARG, &PL_sv_no, MARK, SP);
- else if (SP > MARK)
+ SP = MARK + 1;
+ SETs(TARG);
+ } else if (SP > MARK) {
sv_setsv(TARG, *SP);
- else {
+ SETs(TARG);
+ } else {
sv_setsv(TARG, DEFSV);
- EXTEND(SP, 1);
+ XPUSHs(TARG);
}
up = SvPV_force(TARG, len);
@@ -5659,8 +5662,6 @@ PP(pp_reverse)
}
(void)SvPOK_only_UTF8(TARG);
}
- SP = MARK + 1;
- SETTARG;
}
RETURN;
}
diff --git a/t/op/reverse.t b/t/op/reverse.t
index fd06560..a7d3178 100644
--- a/t/op/reverse.t
+++ b/t/op/reverse.t
@@ -6,7 +6,7 @@ BEGIN {
set_up_inc('../lib');
}
-plan tests => 25;
+plan tests => 26;
is(reverse("abc"), "cba", 'simple reverse');
@@ -105,3 +105,8 @@ SKIP: {
ok defined $a[-1] && ${$a[-1]} eq '1', "in-place reverse strengthens weak reference";
ok defined $a[2] && ${$a[2]} eq '3', "in-place reverse strengthens weak reference in the middle";
}
+
+# [perl #132544] stack pointer used to go wild when nullary reverse
+# required extending the stack
+for(0..1000){()=(0..$_,scalar reverse )}
+pass "extending the stack without crashing";
--
2.1.4
|
|
The RT System itself - Status changed from 'new' to 'open' |
From zefram@fysh.orgI wrote:
Prod. Anyone got an opinion? -zefram |
From @tonycozOn Wed, 13 Dec 2017 12:17:26 -0800, zefram@fysh.org wrote:
We don't really have a fixed policy for this stuff. As a heap buffer overflow it could corrupt the heap, possibly leading to denial of service attacks on some platform, iff an attacker can cause reverse() to execute under right conditions. An attacker has little to no control over the value written to the buffer (an SV pointer). In general I don't think we've treated such overflows as security issues, see #131555 for example. Based on past practice we shouldn't treat this as a security issue. Tony |
From @tonycozOn Thu, 07 Dec 2017 20:21:58 -0800, brian.carpenter@gmail.com wrote:
#131555 is now public. The difference is #131555 it was a simple buffer overflow. In this case we're writing past the end of a buffer that has already been freed - the bug was introduced by the fix for #131555. I had a quick look over the other #131555 fixes, but didn't see any similar problems. Tony |
From @iabynOn Wed, Dec 13, 2017 at 02:44:45PM -0800, Tony Cook via RT wrote:
In which case the new bug hasn't appeared in a production release, so it -- |
From zefram@fysh.orgDave Mitchell wrote:
OK. Fix applied to blead as commit -zefram |
From @tonycozOn Thu, 14 Dec 2017 11:43:57 -0800, zefram@fysh.org wrote:
True, I've moved it to the public queue.
And closed it. Tony |
|
@tonycoz - Status changed from 'open' to 'pending release' |
From @khwilliamsonThank you for filing this report. You have helped make Perl better. With the release yesterday of Perl 5.28.0, this and 185 other issues have been Perl 5.28.0 may be downloaded via: If you find that the problem persists, feel free to reopen this ticket. |
|
@khwilliamson - Status changed from 'pending release' to 'resolved' |
Migrated from rt.perl.org#132544 (status was 'resolved')
Searchable as RT132544$
The text was updated successfully, but these errors were encountered: