Bug 911147
| Summary: | krb5_get_init_creds_keytab() leaks memory | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 6 | Reporter: | Petr Spacek <pspacek> |
| Component: | krb5 | Assignee: | Nalin Dahyabhai <nalin> |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | BaseOS QE Security Team <qe-baseos-security> |
| Severity: | high | Docs Contact: | |
| Priority: | urgent | ||
| Version: | 6.4 | CC: | cww, dpal, ekeck, jplans, ksrot, nalin, nathaniel, nc, pkis, pspacek |
| Target Milestone: | rc | Keywords: | Patch, ZStream |
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | krb5-1.10.3-11.el6 | Doc Type: | Bug Fix |
| Doc Text: |
When the application lookup_etypes_for_keytab() function in krb5-libs attempted to use a keytab file to obtain initial credentials from a KDC, as a preliminary step, it enumerated the set of keys in the keytab to determine which types of keys it possessed. While doing so, it leaked memory. This update adds a krb5_kt_free_entry() call in this loop, and memory leaks no longer occur in the described scenario
|
Story Points: | --- |
| Clone Of: | 911110 | Environment: | |
| Last Closed: | 2013-11-14 10:47:01 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | 911110 | ||
| Bug Blocks: | 978312 | ||
|
Description
Petr Spacek
2013-02-14 13:37:20 UTC
This request was not resolved in time for the current release. Red Hat invites you to ask your support representative to propose this request, if still desired, for consideration in the next release of Red Hat Enterprise Linux. (In reply to comment #0)> AFAIK the memory leak originates in lookup_etypes_for_keytab() function. > File gic_keytab.c:101 contains krb5_kt_next_entry() call in a loop, but > there is no krb5_kt_free_entry() call in this loop. Looks like you're right: there's supposed to be some krb5_free_keytab_entry_contents() action in there. (In reply to Petr Spacek from comment #0) > Steps to Reproduce: > 1. Create program with krb5_get_init_creds_keytab() Could you please attach such a program? Thank you. I guess that any program which works with Kerberos keytab should have this problem.
In my case I hit the bug with BIND/named:
/etc/named.conf contained:
tkey-gssapi-credential "DNS/ipa1.example.com";
tkey-domain "EXAMPLE.COM";
You can use FreeIPA server, it will configure named with Kerberos authentication for you.
Also, you can try kinit -kt , but I didn't try it.
With a simple kinit -k and using a short keytab file I see the following log from valgrind. It looks very similar to the reported one. Nalin, can you confirm that this is the same error or something else? # valgrind --leak-check=yes kinit -k ==2330== Memcheck, a memory error detector ==2330== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al. ==2330== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info ==2330== Command: kinit -k ==2330== ==2330== ==2330== HEAP SUMMARY: ==2330== in use at exit: 728 bytes in 36 blocks ==2330== total heap usage: 54,259 allocs, 54,223 frees, 4,919,337 bytes allocated ==2330== ==2330== 104 bytes in 6 blocks are definitely lost in loss record 2 of 5 ==2330== at 0x4C279EE: malloc (vg_replace_malloc.c:270) ==2330== by 0x5719273: krb5_ktfileint_internal_read_entry (kt_file.c:1375) ==2330== by 0x571AE34: krb5_ktfile_get_next (kt_file.c:1414) ==2330== by 0x572CCF0: krb5_init_creds_set_keytab (gic_keytab.c:101) ==2330== by 0x572D09D: get_init_creds_keytab (gic_keytab.c:242) ==2330== by 0x572D1B2: krb5_get_init_creds_keytab (gic_keytab.c:284) ==2330== by 0x10AAFE: k5_kinit (kinit.c:729) ==2330== by 0x10B775: main (kinit.c:844) ==2330== ==2330== 624 (240 direct, 384 indirect) bytes in 6 blocks are definitely lost in loss record 5 of 5 ==2330== at 0x4C279EE: malloc (vg_replace_malloc.c:270) ==2330== by 0x5718EA3: krb5_ktfileint_internal_read_entry (kt_file.c:1253) ==2330== by 0x571AE34: krb5_ktfile_get_next (kt_file.c:1414) ==2330== by 0x572CCF0: krb5_init_creds_set_keytab (gic_keytab.c:101) ==2330== by 0x572D09D: get_init_creds_keytab (gic_keytab.c:242) ==2330== by 0x572D1B2: krb5_get_init_creds_keytab (gic_keytab.c:284) ==2330== by 0x10AAFE: k5_kinit (kinit.c:729) ==2330== by 0x10B775: main (kinit.c:844) ==2330== ==2330== LEAK SUMMARY: ==2330== definitely lost: 344 bytes in 12 blocks ==2330== indirectly lost: 384 bytes in 24 blocks ==2330== possibly lost: 0 bytes in 0 blocks ==2330== still reachable: 0 bytes in 0 blocks ==2330== suppressed: 0 bytes in 0 blocks ==2330== ==2330== For counts of detected and suppressed errors, rerun with: -v ==2330== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 8 from 6) This looks like the same traceback to me. |