krb5: fix output_token allocators in the GSS debug stub (Windows)
#19064
Conversation
Got hit by curl symbol override: Turns out gssapi_alloc.h defines the GSS allocators as inline functions. When I included it after memdebug.h/curl_memory.h, it started using the curl allocators, and crashed.
|
Confusing results for what I thought was a fix: with the fix, it crashed. Turns out FWIW, the GSS inline implementation looks super risky because it depends |
|
Next snag: Though edit: answer: krb5/krb5@b4ef5a4 |
output_token allocators in the GSS debug stub (Windows)
Before this patch system
malloc()/free()were used to allocatethe buffer returned in the
output_tokenobject from the debug stubof
gss_init_sec_context()when enabled viaCURL_STUB_GSS_CREDSindebug-enabled libcurl builds. This object is later released via stock
gss_release_buffer(), which, in the Windows builds of MIT Kerberos,doesn't use the system
free(), but the Win32HeapFree().Fix it by using the GSS alloc/free macros:
gssalloc_malloc()andgssalloc_free()fromgssapi_alloc.h.To make this work without MIT Kerberos feature detection, use a canary
macro to detect a version which installs
gssapi_alloc.hfor Windows.For <1.15 (2016-11-30) releases, that do not install it, disable the GSS
debug stub in libcurl.
Strictly speaking, non-Windows builds would also need to use GSS
allocators, but, detecting support for
gssapi_alloc.his impossiblewithout build-level logic. Built-level logic is complex and overkill,
and MIT Kerberos, as of 1.22.1, uses standard malloc/free on
non-Windows platforms anyway. (except in GSS debug builds.)
Follow-up to 7384083 #17752
DEBUGBUILDstub feature with <1.18.
I haven't actually tested this with a Windows build, which is also missing
from CI at the moment.