Package: krb5 / 1.12.1+dfsg-19+deb8u4

debian-local/0006-gssapi-never-unload-mechanisms.patch Patch series | download
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
From da1f66cd0cb58cc0a16297c57fc56c91baeb3c26 Mon Sep 17 00:00:00 2001
From: Benjamin Kaduk <kaduk@mit.edu>
Date: Fri, 29 Mar 2013 17:18:40 -0400
Subject: gssapi: never unload mechanisms

It turns out that many GSSAPI mechanisms link to the main gss-api
library creating a circular reference. Depending on how the linker
breaks the cycle at process exit time, the linker may unload the GSS
library after unloading the mechanisms. The explicit dlclose from the
GSS library tends to cause a libdl assertion failure at that
point. So, never unload plugins. They are refcounted, so dlopen
handles will not leak, although obviously the memory from the plugin
is never reclaimed.

ticket: 7135

Patch-Category: debian-local
---
 src/lib/gssapi/mechglue/g_initialize.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/src/lib/gssapi/mechglue/g_initialize.c b/src/lib/gssapi/mechglue/g_initialize.c
index 48a825e..0c37063 100644
--- a/src/lib/gssapi/mechglue/g_initialize.c
+++ b/src/lib/gssapi/mechglue/g_initialize.c
@@ -489,8 +489,6 @@ releaseMechInfo(gss_mech_info *pCf)
 		memset(cf->mech, 0, sizeof(*cf->mech));
 		free(cf->mech);
 	}
-	if (cf->dl_handle != NULL)
-		krb5int_close_plugin(cf->dl_handle);
 	if (cf->int_mech_type != GSS_C_NO_OID)
 		generic_gss_release_oid(&minor_status, &cf->int_mech_type);