Package: krb5 / 1.17-3

debian-local/0005-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 dd3d9bb7d1c07fd5e12b5a0595a8aa351cdaff82 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 0ad11c0b02..a3926e166e 100644
--- a/src/lib/gssapi/mechglue/g_initialize.c
+++ b/src/lib/gssapi/mechglue/g_initialize.c
@@ -559,8 +559,6 @@ releaseMechInfo(gss_mech_info *pCf)
 		generic_gss_release_oid(&minor_status, &cf->mech_type);
 	if (cf->freeMech)
 		zapfree(cf->mech, sizeof(*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);