Bug 1302375 - Intermittent failure in pam_authenticate() call resulting in malloc_printerr () from /lib64/libc.so.6
Intermittent failure in pam_authenticate() call resulting in malloc_printerr ...
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: pam_ldap (Show other bugs)
x86_64 Linux
medium Severity medium
: rc
: ---
Assigned To: Jakub Hrozek
BaseOS QE Security Team
Depends On:
Blocks: 1269194
  Show dependency treegraph
Reported: 2016-01-27 11:22 EST by Greg Scott
Modified: 2016-07-19 16:13 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2016-07-19 16:13:48 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Greg Scott 2016-01-27 11:22:29 EST
Description of problem:

Customer has a web application that is using the pam_authenticate() call to validate user logins.

Intermittently it fails with:  

#0  0x0000003944232635 in raise () from /lib64/libc.so.6
#1  0x0000003944233e15 in abort () from /lib64/libc.so.6
#2  0x0000003944270547 in __libc_message () from /lib64/libc.so.6
#3  0x0000003944275e76 in malloc_printerr () from /lib64/libc.so.6
#4  0x00007f101c79fc74 in ldap_pvt_tls_set_option () from /lib64/libldap-2.4.so.2
#5  0x00007f101c7954b6 in ldap_set_option () from /lib64/libldap-2.4.so.2
#6  0x00007f10251f2a8f in ?? () from /lib64/security/pam_ldap.so
#7  0x00007f10251f5428 in ?? () from /lib64/security/pam_ldap.so
#8  0x00007f10251f56c1 in ?? () from /lib64/security/pam_ldap.so
#9  0x00007f10251f66f3 in ?? () from /lib64/security/pam_ldap.so
#10 0x00007f10251f6acb in pam_sm_authenticate () from /lib64/security/pam_ldap.so
#11 0x0000003944602cee in ?? () from /lib64/libpam.so.0
#12 0x0000003944602600 in pam_authenticate () from /lib64/libpam.so.0
#13 0x00000000005fdde5 in authenticateUsingPAM (pam_service="su", password="xxxxxx", name="achen1") at AuthWebServerHandler.C:78
#14 hfb::isValidUnixPassword (name="achen1", password="Dyingwind1", pam_service="su") at AuthWebServerHandler.C:149
#15 0x0000000000610e99 in hfb::WebServerHandler::run (this=0x2c52a20, socket=...) at WebServerHandler.C:391
#16 0x0000000000601ad5 in hfb::ServerHandler::Connection::run (this=0x7f1028004cb0) at Socket.C:1547
#17 0x000000000060a5cb in hfb::Thread::run_S (arg=0x7f1028004d30) at Thread.C:452
#18 0x0000003944e079d1 in start_thread () from /lib64/libpthread.so.0
#19 0x00000039442e886d in clone () from /lib64/libc.so.6

Customer believes this may be a bug in the libpam code that also existed in the autofs module, which has been recently fixed. See BZ number 1084254 for the automount issue.

Does the bug fix for the autofs/ldap issue noted above also apply here?

The source code making the call is as follows:

static bool authenticateUsingPAM( const std::string & name, const std::string & password, const std::string& pam_service )
    pam_handle_t *pamh = 0;
    pam_conv conv;
    conv.conv = &conv_f;
    conv.appdata_ptr = strdup(password.c_str());
    int retval = pam_start( pam_service.c_str(), name.c_str(), &conv, &pamh );
    if( retval == PAM_SUCCESS )
        retval = pam_authenticate(pamh, PAM_DISALLOW_NULL_AUTHTOK);
    if( retval != PAM_SUCCESS)
        std::cerr << pam_strerror(pamh, retval) << std::endl;
        return false;
    pam_end(pamh, 0);
    return true;

Version-Release number of selected component (if applicable): RHEL 6.5

How reproducible:

Steps to Reproduce:
1. hard to reproduce, but possibly after a large number of calls in quick succession.

Actual results:
Intermittant app crashes described above.

Expected results:
pam_authenticate should not return ugly stack dumps.

Additional info:
Comment 1 Tomas Mraz 2016-01-27 11:25:27 EST
This is most probably a problem in pam_ldap.
Comment 12 Greg Scott 2016-02-01 08:00:21 EST
Jakub, I posted your question in the support case.  As soon as I get back anything, I'll make sure it goes in here.  I'll keep the needsinfo turned on.

- Greg
Comment 13 Greg Scott 2016-07-18 08:51:36 EDT
Clearing the needsinfo flag here.  The bz is closed and so is the SFDC case that generated it.  No sense leaving that flag set.

- Greg
Comment 14 Jakub Hrozek 2016-07-19 16:13:48 EDT
Thank you for the bug report.

Since RHEL-6 is transitioning to production phase 2 and we don't have a reproducer (or, at this point, an open case either), I'm going to close this bug as WONTFIX.

Note You need to log in before you can comment on or make changes to this bug.