Menu
▾
▴
#809 __tmainCRTStartup: copied argv causing memory leakage
crt/crtexe.c(__tmainCRTStartup): The array argv duplicated by duplicate_ppstrings seems to create memory leakage, since it is not freed up until the process is terminated.
Is this something you consider to be remedied - or was it a deliberate decision to omit freeing argv up?
Mem leakage detection tools complain about this which interferes an otherwise clean mem leakage report.
Many thanks!
Hello,
this memory leakage is well known. We could have used here instead
stack, which would be even worse. As it would allow attacker to
manipulate directly on stack with known layout.
Anyway, we could use here instead Win32 API to allocate, and free it
later by Win32. A patch for this would be welcome.
Regards,
Kai
Am Do., 25. Juli 2019 um 17:29 Uhr schrieb Jannick
jannick0815@users.sourceforge.net:
Related
Bugs: #809
Hi Kai,
Happy to suggest a patch. Just to confirm: Would GetProcessHeap / HeapAlloc
/ HeapFree be the WIN32 API functions you expect to be used?
Regards,
J.
From: Kai Tietz ktietz70@users.sourceforge.net
Sent: Tuesday, August 6, 2019 10:44 AM
To: [mingw-w64:bugs] 809@bugs.mingw-w64.p.re.sourceforge.net
Subject: [mingw-w64:bugs] Re: #809 __tmainCRTStartup: copied argv causing
memory leakage
Hello,
this memory leakage is well known. We could have used here instead
stack, which would be even worse. As it would allow attacker to
manipulate directly on stack with known layout.
Anyway, we could use here instead Win32 API to allocate, and free it
later by Win32. A patch for this would be welcome.
Regards,
Kai
Am Di., 6. Aug. 2019 um 12:06 Uhr schrieb Jannick
jannick0815@users.sourceforge.net:
As crt creates a heap, and we want that arguments remain valid as long
as possible TLS-routines might be executed on exit, it would be best
to use here GlobalAlloc (well LocalAlloc is actually the same!). Of
most interesting is here the point, when this memory is getting
destroyed.
Such a patch needs some more extentive testing!
Regards,
Kai
Umm ... Section 5.1.2.2.1 of C11 (Program startup) might be an obstacle to
naively free up argv at some point:
"The parameters argc and argv and the strings pointed to by the argv array
shall be modifiable by the program, and retain their last-stored values
between program startup and program termination."
I am inclined to interpret the term 'modifiable' to allow the program to
change the strings pointed to by the argv array including reallocations. If
true the program could legally free up those strings and/or reallocate and
free argv. This would be a showstopper to naively free up argv at some
point. Agree?
I believe that the section cited above did not change since early C
standards.
You are correct with respect to the modifiable values C89 2.1.2.2 Hosted environment specifies this exact behavior. I haven't looked at C11 but I do remember that the pointers in the array are implementation defined, but non-const. Basically it boils down to argc and argv are owned by the program once they are passed to main.
Note: Program termination is the return from main or call to exit()
Programs are free to:
1) Modify the value in argv[i][j] , where j is an index up to and including the NULL terminator.
2) Modify the the value of argv[i] to point to a different location.
It is undefined behavior to realloc or free either argv or argv[i], because these are implementation defined values and as they were not allocated by the program with malloc, calloc, or realloc). A program may only free or realloc something that it itself has malloc/calloc/or realloced.
That being said, it should be possible to use the windows allocation routines instead of the CRT routines to allocate the memory passed to main.