-
Notifications
You must be signed in to change notification settings - Fork 586
Description
Description
Its very rare nowadays for the interp to show instant heap corruption or instant buffer overflows, from basic, simple, non-fuzzing PP production code, but I randomly ran into this 5 mins ago.
I will probably fix this myself in another PR in the near future since it is for sure something basic and the pp_*()
that implements that OP_CODE probably needs its 10 year scheduled cleanup of its XS macros choices.
Also is this buffer overflow a WinPerl only bug or an AnyOS Perl bug?
Steps to Reproduce
Perl executable: C:\Strawberry\sp2464\perl\bin\perl.exe
Perl version : 5.24.4 / MSWin32-x64-multi-thread
C:\Strawberry\sp2464>perl -e"print gethostbyname(undef);"
LVT42024└¿☺u└¿☺♫└¿8☺
C:\Strawberry\sp2464>
C:\p42rc0>perl -e"print gethostbyname(undef);"
LVT42024└¿☺u└¿☺♫└¿8☺
C:\p42rc0>perl -v
This is perl 5, version 42, subversion 0 (v5.42.0-RC1-3-g8b524d3ea2c*) built for
MSWin32-x64-multi-thread
(with 1 registered patch, see perl -V for more detail)
Copyright 1987-2025, Larry Wall
Expected behavior
the "LVT420"
is legit, the rest of the buffer is not.
LVT42024=C0=A8=01u=C0=A8=01=0E=C0=A88=01
4C 56 54 34 32 30 32 34 C0 A8 01 75 C0 A8 01 0E
C0 A8 38 01
My quick and dirty attempt at a hex dump of that string. There might be a very different byte sequence sitting in VM addr space if someone BPs it and examines the SV* on a C level.
Perl configuration
see above for -v