Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-RT-Original-Encoding: us-ascii
Content-Length: 1441

Originator:     Corene Casper
Organization:   Dell EMC
Confidential:   no
Synopsis:       memory leak via krb5_rc_none_close
Severity:       non-critical
Priority:       low
Category:       krb5-libs
Class:          sw-bug
Release:        1.14
Environment:
        system:  Isilon OneFS v8.1.0  (freebsd-11.0 based)
        machine: amd64
Description:
        When using the krb5_rc_none_ops cache type, a k5_mutex_t structure
        is being leaked on every close.  We've run into the case where our
        application has been up for long enough that it finally ran
        the system out of memory due to this leak.
How-To-Repeat:
        Configure your system so it uses "none" rc cache type and then
        exercise that code path repeatedly and observe process slowly
        grow in size.
        (In our case, this was in our SMB server code.  With Kerberos
        configured, each SESSION_SETUP user authentication resulted
        in a leak of one k5_mutex_t).
Fix:    one-line patch to krb5_rc_none_close, to add the k5_mutex_destroy()
        call:
*** isilon/fsp/krb5/src/lib/krb5/rcache/rc_none.c       2019-02-13 15:22:42.251051611 -0800
--- /tmp/NDbjMy_rc_none.c       2019-02-13 15:23:46.331514547 -0800
***************
*** 50,56 ****
  static krb5_error_code KRB5_CALLCONV
  krb5_rc_none_close(krb5_context ctx, krb5_rcache rc)
  {
-     k5_mutex_destroy(&rc->lock);
      free (rc);
      return 0;
  }
--- 50,55 ----