| Subject: | SIGABRT caused when calling gss_release_oid for an OID that should not be released |
Hi,
This is with MIT krb5 1.14.4 on Fedora 25 and 1.14.1 on CentOS7.3.
This is with MIT krb5 1.14.4 on Fedora 25 and 1.14.1 on CentOS7.3.
When passing a scalar for the `mech_type` argument to `GSSAPI::Context::accept`,
an OID is created. When this goes out of scope, `gss_release_oid` is called,
which causes an ABRT in `generic_gss_release_oid` from libgssapi_krb5.so.2.
From https://tools.ietf.org/html/rfc2744 (abbreviated):
```
mech_type The returned OID value will be a pointer
into static storage, and should be treated as
read-only by the caller (in particular, it does
not need to be freed).
```
I don't see any way to know which OIDs need to be freed just from their
properties, so the simplest solution seems to be to just not call
`gss_release_oid`. MIT appears to be the only implementation that has
`gss_release_oid`. It is also not part of the RFC.
I've attached a small patch which does that, but I assume this will cause memory
leaks for some people and needs to be tested.
Thanks
I've attached a small patch which does that, but I assume this will cause memory
leaks for some people and needs to be tested.
Thanks
| Subject: | 0001-Trying-to-release-mech_type-OID-from-gss_accept_sec_.patch |
From 595335a269a78eb3ee12ddb285aa6eb759e127b1 Mon Sep 17 00:00:00 2001
From: Ioan Rogers <ioan.rogers@sophos.com>
Date: Wed, 24 May 2017 12:22:25 -0700
Subject: [PATCH] Trying to release mech_type OID from gss_accept_sec_context
causes SIGABRT
This is with MIT krb5 1.14.4.
When passing a scalar for the `mech_type` argument to `GSSAPI::Context::accept`,
an OID is created. When this goes out of scope, `gss_release_oid` is called,
which causes an ABRT in `generic_gss_release_oid` from libgssapi_krb5.so.2.
From https://tools.ietf.org/html/rfc2744 (abbreviated):
```
mech_type The returned OID value will be a pointer
into static storage, and should be treated as
read-only by the caller (in particular, it does
not need to be freed).
```
I don't see any way to know which OIDs need to be freed just from their
properties, so the simplest solution seems to be to just not call
`gss_release_oid`. MIT appears to be the only implementation that has
`gss_release_oid`. It is also not part of the RFC.
`gss_release_oid` also performs the flag checks removed here.
---
xs/OID.xs | 21 ---------------------
1 file changed, 21 deletions(-)
diff --git a/xs/OID.xs b/xs/OID.xs
index c805e45..11f4d11 100644
--- a/xs/OID.xs
+++ b/xs/OID.xs
@@ -7,27 +7,6 @@ new(class)
OUTPUT:
RETVAL
-void
-DESTROY(oid)
- GSSAPI::OID oid
- PREINIT:
- OM_uint32 minor;
- PPCODE:
-#if !defined(HEIMDAL)
- if (oid != NULL &&
- oid != __KRB5_MECHTYPE_OID &&
- oid != __KRB5_OLD_MECHTYPE_OID &&
- oid != __GSS_KRB5_NT_USER_NAME &&
- oid != __GSS_KRB5_NT_PRINCIPAL_NAME &&
- oid != __SPNEGO_MECHTYPE_OID &&
- oid != __gss_mech_krb5_v2 ) {
- (void)gss_release_oid(&minor, &oid);
- }
-#endif
-#if defined(HEIMDAL)
-# warn("gss_release_oid is unsupported and not Part of the API!");
-#endif
-
GSSAPI::Status
from_str(class, oid, str)
char * class
--
2.9.4