Heimdal 7.5.0 memory leaks
"Markus Moeller" <[email protected]> Sat, 15 Sep 2018 18:47:52 +0100
| Newsgroups | gmane.comp.encryption.kerberos.heimdal.general |
|---|---|
| Message-ID | <9907EC78D4F0491D942F98DFF418C16F__48606.3068769456$1537033616$gmane$org@Ultrabook1> |
This is a multi-part message in MIME format.
------=_NextPart_000_0059_01D44D24.9BA15530
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Hi,
I looked at memory leaks for the squid negotiate_kerberos helper and =
found issues with the following in the heimdal code:
=3D=3D9424=3D=3D 16 bytes in 1 blocks are definitely lost in loss record =
13 of 64
=3D=3D9424=3D=3D at 0x4C2A110: malloc (in =
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
=3D=3D9424=3D=3D by 0x52ACF9C: set_etypes (context.c:74)
=3D=3D9424=3D=3D by 0x52ADE8F: init_context_from_config_file =
(context.c:161)
=3D=3D9424=3D=3D by 0x52ADE8F: krb5_set_config_files (context.c:692)
=3D=3D9424=3D=3D by 0x52AE49C: krb5_init_context (context.c:451)
=3D=3D9424=3D=3D by 0x4023C1: main (negotiate_kerberos_auth.cc:549)
which should be fixed with
--- lib/krb5/context.c 2017-12-07 04:11:23.000000000 +0000
+++ lib/krb5/context_new.c 2018-09-15 18:45:40.715744342 +0100
@@ -622,6 +622,9 @@
free(context->etypes);
free(context->cfg_etypes);
free(context->etypes_des);
+ free(context->permitted_enctypes);
+ free(context->tgs_etypes);
+ free(context->as_etypes);
krb5_free_host_realm (context, context->default_realms);
krb5_config_file_free (context, context->cf);
free_error_table (context->et_list);
and=20
=3D=3D9424=3D=3D 13,200 bytes in 6 blocks are definitely lost in loss =
record 63 of 64
=3D=3D9424=3D=3D at 0x4C2C240: calloc (in =
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
=3D=3D9424=3D=3D by 0x4E5E01A: _gss_ntlm_allocate_ctx =
(accept_sec_context.c:52)
=3D=3D9424=3D=3D by 0x4E5E5B4: _gss_ntlm_acquire_cred =
(acquire_cred.c:60)
=3D=3D9424=3D=3D by 0x4E55779: gss_acquire_cred =
(gss_acquire_cred.c:125)
=3D=3D9424=3D=3D by 0x4E635AB: _gss_spnego_acquire_cred =
(cred_stubs.c:109)
=3D=3D9424=3D=3D by 0x4E55779: gss_acquire_cred =
(gss_acquire_cred.c:125)
=3D=3D9424=3D=3D by 0x403227: main (negotiate_kerberos_auth.cc:721)
Which could be fixed with
--- ./lib/gssapi/ntlm/acquire_cred.c 2016-12-20 14:23:06.000000000 =
+0000
+++ ./lib/gssapi/ntlm/acquire_cred_new.c 2018-09-15 =
18:09:04.436985518 +0100
@@ -58,8 +58,10 @@
if (cred_usage =3D=3D GSS_C_BOTH || cred_usage =3D=3D GSS_C_ACCEPT) =
{
maj_stat =3D _gss_ntlm_allocate_ctx(min_stat, &ctx);
- if (maj_stat !=3D GSS_S_COMPLETE)
+ if (maj_stat !=3D GSS_S_COMPLETE) {
+ if (ctx) free(ctx);
return maj_stat;
+ }
domain =3D name !=3D NULL ? name->domain : NULL;
maj_stat =3D (*ctx->server->nsi_probe)(min_stat, ctx->ictx, =
domain);
Markus
------=_NextPart_000_0059_01D44D24.9BA15530
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<HTML><HEAD></HEAD>
<BODY dir=3Dltr>
<DIV dir=3Dltr>
<DIV style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Arial'; COLOR: #000000">
<DIV>Hi,</DIV>
<DIV> </DIV>
<DIV> I looked at memory leaks for the squid =
negotiate_kerberos=20
helper and found issues with the following in the heimdal code:</DIV>
<DIV> </DIV>
<DIV>=3D=3D9424=3D=3D 16 bytes in 1 blocks are definitely lost in loss =
record 13 of=20
64</DIV>
<DIV>=3D=3D9424=3D=3D at 0x4C2A110: malloc (in=20
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)</DIV>
<DIV>=3D=3D9424=3D=3D by 0x52ACF9C: set_etypes =
(context.c:74)</DIV>
<DIV>=3D=3D9424=3D=3D by 0x52ADE8F: =
init_context_from_config_file=20
(context.c:161)</DIV>
<DIV>=3D=3D9424=3D=3D by 0x52ADE8F: =
krb5_set_config_files=20
(context.c:692)</DIV>
<DIV>=3D=3D9424=3D=3D by 0x52AE49C: krb5_init_context=20
(context.c:451)</DIV>
<DIV>=3D=3D9424=3D=3D by 0x4023C1: main=20
(negotiate_kerberos_auth.cc:549)</DIV>
<DIV> </DIV>
<DIV>which should be fixed with</DIV>
<DIV> </DIV>
<DIV>--- lib/krb5/context.c 2017-12-07 04:11:23.000000000 =
+0000</DIV>
<DIV>+++ lib/krb5/context_new.c 2018-09-15 =
18:45:40.715744342 +0100</DIV>
<DIV>@@ -622,6 +622,9 @@</DIV>
<DIV> free(context->etypes);</DIV>
<DIV> free(context->cfg_etypes);</DIV>
<DIV> free(context->etypes_des);</DIV>
<DIV>+ free(context->permitted_enctypes);</DIV>
<DIV>+ free(context->tgs_etypes);</DIV>
<DIV>+ free(context->as_etypes);</DIV>
<DIV> krb5_free_host_realm (context,=20
context->default_realms);</DIV>
<DIV> krb5_config_file_free (context,=20
context->cf);</DIV>
<DIV> free_error_table =
(context->et_list);</DIV>
<DIV></DIV>
<DIV> </DIV>
<DIV>and </DIV>
<DIV> </DIV>
<DIV>=3D=3D9424=3D=3D 13,200 bytes in 6 blocks are definitely lost in =
loss record 63 of=20
64</DIV>
<DIV>=3D=3D9424=3D=3D at 0x4C2C240: calloc (in=20
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)</DIV>
<DIV>=3D=3D9424=3D=3D by 0x4E5E01A: =
_gss_ntlm_allocate_ctx=20
(accept_sec_context.c:52)</DIV>
<DIV>=3D=3D9424=3D=3D by 0x4E5E5B4: =
_gss_ntlm_acquire_cred=20
(acquire_cred.c:60)</DIV>
<DIV>=3D=3D9424=3D=3D by 0x4E55779: gss_acquire_cred=20
(gss_acquire_cred.c:125)</DIV>
<DIV>=3D=3D9424=3D=3D by 0x4E635AB: =
_gss_spnego_acquire_cred=20
(cred_stubs.c:109)</DIV>
<DIV>=3D=3D9424=3D=3D by 0x4E55779: gss_acquire_cred=20
(gss_acquire_cred.c:125)</DIV>
<DIV>=3D=3D9424=3D=3D by 0x403227: main=20
(negotiate_kerberos_auth.cc:721)</DIV>
<DIV> </DIV>
<DIV>Which could be fixed with</DIV>
<DIV> </DIV>
<DIV>--- ./lib/gssapi/ntlm/acquire_cred.c 2016-12-20=20
14:23:06.000000000 +0000</DIV>
<DIV>+++=20
./lib/gssapi/ntlm/acquire_cred_new.c &=
nbsp;=20
2018-09-15 18:09:04.436985518 +0100</DIV>
<DIV>@@ -58,8 +58,10 @@</DIV>
<DIV> if (cred_usage =3D=3D GSS_C_BOTH || =
cred_usage =3D=3D=20
GSS_C_ACCEPT) {</DIV>
<DIV> </DIV>
<DIV> maj_stat =3D=20
_gss_ntlm_allocate_ctx(min_stat, &ctx);</DIV>
<DIV>- if (maj_stat !=3D =
GSS_S_COMPLETE)</DIV>
<DIV>+ if (maj_stat !=3D =
GSS_S_COMPLETE)=20
{</DIV>
<DIV>+ if =
(ctx)=20
free(ctx);</DIV>
<DIV> =
return=20
maj_stat;</DIV>
<DIV>+ }</DIV>
<DIV> </DIV>
<DIV> domain =3D name =
!=3D NULL ?=20
name->domain : NULL;</DIV>
<DIV> maj_stat =3D=20
(*ctx->server->nsi_probe)(min_stat, ctx->ictx, domain);</DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV>Markus</DIV>
<DIV> </DIV>
<DIV> </DIV></DIV></DIV></BODY></HTML>
------=_NextPart_000_0059_01D44D24.9BA15530--