Hide Forgot
Created attachment 478617 [details] Reproducer Description of problem: Function pam_authenticate() from pam-devel crash with segmentation fault when using SSL or TLS in pam_ldap. I am testing BZ#511238 Version-Release number of selected component (if applicable): pam_ldap-185-6.el6 pam-devel-1.1.1-6.el6 How reproducible: Always. Steps to Reproduce: 1. Configure pam_ldap to use SSL/TLS: cat >etc/pam_ldap.conf<<EOF uri ldap://ldap.bos.redhat.com ssl start_tls #uri ldaps://ldap.bos.redhat.com #ssl yes tls_cacertdir /etc/openldap/cacerts base dc=redhat,dc=com EOF 2. Configure pam_ldap pam module: cat >/etc/pam.d/pam_ldap<<EOF auth required pam_ldap.so account required pam_permit.so EOF 3. Compile attached reproducer: gcc -g -o pam_test pam_test.c -lpam 4. Execute it: ./pam_test pamtest foo 5 Actual results: Preparing to test through 5 iterations. total 2508K Iteration # 1 pam_authenticate failed: User not known to the underlying authentication module Iteration # 2 pam_authenticate failed: User not known to the underlying authentication module Iteration # 3 Segmentation fault (core dumped) Expected results: No segmentation fault. Additional info: This was revealed while retesting bug BZ#511238. Everything works fine if SSL/TLS is disabled.
I forgot to mention that you need to install RH cert as follows: # wget -c -O /etc/openldap/cacerts/redhat.pem \ http://password.corp.redhat.com/newca.crt \ --no-check-certificate # cacertdir_rehash /etc/openldap/cacerts
Hmm, I'm not seeing the crash on my x86_64 system (tried with 100 iterations, just in case), but the leak's there (the change hadn't been forward-ported yet).
You're right Nalin, I cannot hit the bug on x86_64 neither. Try auto-i386-002.ss.eng.bos.redhat.com (root/fo0m4nchU). I see the bug on two different i386 machines. However sometimes it crashes just after a few iterations and sometimes it needs more than 100 iterations. The last lines of strace output are always as follows: socket(PF_INET, SOCK_DGRAM|SOCK_NONBLOCK, IPPROTO_IP) = 3 connect(3, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("10.16.36.29")}, 16) = 0 gettimeofday({1297760784, 185708}, NULL) = 0 poll([{fd=3, events=POLLOUT}], 1, 0) = 1 ([{fd=3, revents=POLLOUT}]) send(3, "\220,\1\0\0\1\0\0\0\0\0\0\rauto-i386-002\2ss\3en"..., 53, MSG_NOSIGNAL) = 53 poll([{fd=3, events=POLLIN}], 1, 5000) = 1 ([{fd=3, revents=POLLIN}]) ioctl(3, FIONREAD, [141]) = 0 recvfrom(3, "\220,\201\200\0\1\0\1\0\2\0\2\rauto-i386-002\2ss\3en"..., 1024, 0, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("10.16.36.29")}, [16]) = 141 close(3) = 0 --- SIGSEGV (Segmentation fault) @ 0 (0) --- +++ killed by SIGSEGV (core dumped) +++ Segmentation fault (core dumped)
Created attachment 478943 [details] simpler reproducer Run as "env MALLOC_CHECK_=3 ./dlopen2 libldap.so 100", this crashes pretty reliably with newer libldap, in the same place, but doesn't with older libldap.
I think the important difference here is that we're loading and unloading the LDAP library repeatedly, and using its TLS support each time. If we link pam_ldap to keep it from being unloaded, we'll stop running into it here, but the crash won't be fixed for the general case. CCing the openldap package maintainer.
Hi, Please be so kind and add a few key words to the technical note of this Bugzilla entry using the following structure: Cause: Consequence: Fix: Result: For details, see: https://bugzilla.redhat.com/page.cgi?id=fields.html#cf_release_notes Thanks
Technical note added. If any revisions are required, please edit the "Technical Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. New Contents: Cause What actions or circumstances cause this bug to present. Consequence What happens when the bug presents. Fix What was done to fix the bug. Result What now happens when the actions or circumstances above occur. Note: this is not the same as the bug doesn’t present anymore.
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHBA-2011-0688.html