Bug 18063 - A dynamically allocated string is referenced after it has been freed in the internals of GetHostByName
Summary: A dynamically allocated string is referenced after it has been freed in the i...
Alias: None
Product: Runtime
Classification: Mono
Component: JIT ()
Version: unspecified
Hardware: PC Windows
: --- normal
Target Milestone: ---
Assignee: Bugzilla
Depends on:
Reported: 2014-02-27 21:04 UTC by Mike Biddlecombe
Modified: 2014-02-28 11:34 UTC (History)
4 users (show)

Is this bug a regression?: ---
Last known good build:

Notice (2018-05-24): bugzilla.xamarin.com is now in read-only mode.

Please join us on Visual Studio Developer Community and in the Xamarin and Mono organizations on GitHub to continue tracking issues. Bugzilla will remain available for reference in read-only mode. We will continue to work on open Bugzilla bugs, copy them to the new locations as needed for follow-up, and add the new items under Related Links.

Our sincere thanks to everyone who has contributed on this bug tracker over the years. Thanks also for your understanding as we make these adjustments and improvements for the future.

Please create a new report on GitHub or Developer Community with your current version information, steps to reproduce, and relevant error messages or log files if you are hitting an issue that looks similar to this resolved bug and you do not yet see a matching new report.

Related Links:

Description Mike Biddlecombe 2014-02-27 21:04:29 UTC
There are two flavours of the 'ves_icall_System_Net_Dns_GetHostByName_internal' function in which a temporary 'hostname' string is not cleaned up safely.

The locations in ...mono/metadata/socket-io.c that seem suspicious are:

Line 3020 -- the string may leak if the call to getaddrinfo() fails (and we return early):

	if (*hostname && getaddrinfo(hostname, NULL, &hints, &info) == -1) {


Line 3109 -- a pointer dereference is made after it the string is freed:


	if (*hostname && he==NULL)

It was this second case that I encountered when I tried launching the Unity3D game engine's editor with Page Heap debugging enabled (I was using the Windows gflags.exe tool to tweak the way Unity.exe is run). Unity3d is built on top of Mono and I wanted to enable the Page Heap to debug memory stomp in my own dll but I wasn't able to get past an access violation that occurs when Unity3D launches.

I'm not yet familiar with Mono and how it is integrated into Unity3D, so I'm not sure of the exact version of Mono I'm running, or even the correct Class library to cite here, but I compared the disassembled code I was halted on with source I located on Github and it sure looks like this is the problem I'm seeing.

This is my first time submitting a bug, so please take that into consideration if I've missed something critical.
Comment 1 Zoltan Varga 2014-02-28 11:34:50 UTC
Fixed in 342418201c4599021cd32f2880b308cb8ff9c221. Thanks for the report. You might want to notify unity about this problem too since they use their own version of mono