New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
heap-use-after-free in Perl_sv_setpv_bufsize (perl/sv.c:4918:17) #17084
Comments
From imdb95@gmail.comHello, **********Compilation and environment********** This is perl 5, version 31, subversion 2 (v5.31.2 (v5.31.1-6-g9649a81)) Copyright 1987-2019, Larry Wall Perl may be copied only under the terms of either the Artistic License or Complete documentation for Perl, including FAQ lists, should be found on root@instance-2:~/fuzz_perl# uname -a root@instance-2:~/fuzz_perl# lsb_release -r Compilation: The bug also occurs in default perl version for Ubuntu 16.04. **********Reproduce-1**********
|
From @iabynOn Sat, Jul 06, 2019 at 12:34:46PM -0700, Nguyen Duc Manh wrote:
These all look like stack-not-refcounted bugs, and I don't think they're
It aliases the '|' typeglob (i.e. $| etc) to the typeglob '2' (i.e. $2 So its the same as *| = *2 -- |
The RT System itself - Status changed from 'new' to 'open' |
From imdb95@gmail.comOn Mon, Jul 8, 2019 at 4:18 PM Dave Mitchell via RT <
Can you explain why it is not a security issue when heap-use-after-free Thanks, |
From @tonycozOn Mon, 08 Jul 2019 03:34:38 -0700, imdb95@gmail.com wrote:
We've had some debate on whether to treat such issues as security issues. The base cause of this and similar bugs is that the perl parameter/return stack isn't reference counted, and when normal variables are pushed onto the stack they don't get a reference count increment with delayed decrement like typical return values do. So in your code the value of But such problems are implicit in the structure of the code rather than due to any data that the code might read. For example in your case doing: *| = 2; prevents the problem; It may be that the code in some other case might only see this type of problem with a limited set of inputs (eg. a function that's included in a list might only clear an array also included in that list in a limited set of circumstances), but the problem is still implicit in the structure of the code. My example[1]: sub foo { # dangerous: While we don't treat this issue as a security issue, we do still consider it a bug, but a very complex to fix bug, especially if we want to a) retain compatibility with existing XS code on CPAN and b) still allow that code adapt to use a refcounted stack but retain compatibility with older versions of perl. Tony [1] this code is bad due to the action at a distance anyway |
From @iabynOn Mon, Aug 05, 2019 at 06:29:21PM -0700, Tony Cook via RT wrote:
I propose that this ticket gets moved to the public queue. -- |
From @tonycozOn Wed, 07 Aug 2019 01:58:17 -0700, davem wrote:
Now public. Tony |
Migrated from rt.perl.org#134269 (status was 'open')
Searchable as RT134269$
The text was updated successfully, but these errors were encountered: