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
PERL-5.26.1 heap_use_after_free WRITE of size 8 #16313
Comments
From sraums2498@gmail.com================================================================= 0x619000009a70 is located 1008 bytes inside of 1024-byte region previously allocated by thread T0 here: SUMMARY: AddressSanitizer: heap-use-after-free -- |
From sraums2498@gmail.com |
From @iabynOn Mon, Dec 18, 2017 at 03:38:23AM -0800, SRAUMS JN wrote:
This is a regression that was introduced into blead with The fault is in pp_list using EXTEND() rather than MEXTEND(), so if the I think it would be hard to find code in the wild which could exploit 1) pp_list() would have to be called in scalar context, which doesn't 2) pp_list has to be called with the stack filled exactly to the brim, Once triggered, the effects are 1) pp_list will randomly return (...)[-1] or &PL_sv_undef - normally 2) On return, PL_stack_sp will point to the old freed stack, so any I have a fix for this, and also a fix for a similar issue in pp_warn, Here's a test I added which triggers the behaviour: fresh_perl_is(<<'EOF', "OK\n", {stderr => 1}, "RT #132602"); The OP_LIST is in the f sub, which doesn't know until runtime whether to Once the pp_list fix is pushed, it needs backporting to maint-5.26 too. My feeling is that since this is hard enough to exploit, and has been in -- |
The RT System itself - Status changed from 'new' to 'open' |
From @tonycozOn Wed, 20 Dec 2017 06:46:41 -0800, davem wrote:
It's potentially a denial of service in that a write to the freed block might crash perl (the memory may no longer be mapped), or corrupt the arena, leading to a crash later on. But as you say, it's unlikely for pp_list to be used in scalar context, and it's very unlikely the stack will be filled to the brim, so I agree this isn't a useful denial of service, and the lack of control over the value written (it's a pointer) means I don't think this can be used for any sort of code execution attack. If the new block allocated when the stack was reallocated contained SV pointers (such as the AvARRAY() from an AV) it may be possible to use this for some sort of information disclosure, since the next SV popped from he stack will be the previous SV pointer[1], but with the unlikelyhood of the pre-conditions I don't think this is realistically exploitable. So I agree this isn't a security issue. Tony [1] AvREAL() arrays have the new entries cleared, but the stack isn't |
From @tonycozOn Tue, 30 Jan 2018 16:53:24 -0800, tonyc wrote:
Moved to the public queue. Tony |
From @tonycozOn Wed, 20 Dec 2017 06:46:41 -0800, davem wrote:
I think the original issue here was fixed in 57bd660 (perl #131954), but Tony |
From @iabynOn Tue, Jan 30, 2018 at 04:59:24PM -0800, Tony Cook via RT wrote:
Ah yes, I forgot to push it. Pushed now as v5.27.8-140-g8d629a7. -- |
@iabyn - Status changed from 'open' to 'resolved' |
Migrated from rt.perl.org#132602 (status was 'resolved')
Searchable as RT132602$
The text was updated successfully, but these errors were encountered: