Skip to content

keyword gethostbyname() <= 5.24.0-5.43.1 buffer overflow/heap corruption (update: docs bug) #23463

@bulk88

Description

@bulk88

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

Metadata

Metadata

Assignees

No one assigned

    Labels

    Closable?We might be able to close this ticket, but we need to check with the reporter

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions