Bug 1269409 - libpopt: use-after-free error seen on valgrind log
Summary: libpopt: use-after-free error seen on valgrind log
Keywords:
Status: CLOSED INSUFFICIENT_DATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: popt
Version: 7.2
Hardware: All
OS: Linux
unspecified
medium
Target Milestone: rc
: ---
Assignee: Florian Festi
QA Contact: BaseOS QE - Apps
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-10-07 08:58 UTC by Amith
Modified: 2019-02-14 08:38 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-02-14 08:38:09 UTC
Target Upstream Version:


Attachments (Terms of Use)

Description Amith 2015-10-07 08:58:53 UTC
Description of problem:
This one was observed while verifying BZ1254518. The valgrind log shows following error:

==18031== 2 errors in context 1 of 1:
==18031== Invalid read of size 4
==18031==    at 0x52A8928: ??? (in /usr/lib64/libpopt.so.0.0.0)
==18031==    by 0x52A92FA: poptGetNextOpt (in /usr/lib64/libpopt.so.0.0.0)
==18031==    by 0x10DDF0: ??? (in /usr/libexec/sssd/sssd_nss)
==18031==    by 0x8FD9B14: (below main) (libc-start.c:274)
==18031==  Address 0xba6b5e0 is 0 bytes inside a block of size 2 alloc'd
==18031==    at 0x4C29BFD: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==18031==    by 0x52A881E: ??? (in /usr/lib64/libpopt.so.0.0.0)
==18031==    by 0x52A92FA: poptGetNextOpt (in /usr/lib64/libpopt.so.0.0.0)
==18031==    by 0x10DDF0: ??? (in /usr/libexec/sssd/sssd_nss)
==18031==    by 0x8FD9B14: (below main) (libc-start.c:274)


Version-Release number of selected component (if applicable):
popt Version - popt-1.13-16.el7.x86_64
SSSD Version - sssd-1.13.0-26.el7.x86_64 (If necessary)

How reproducible:
Always

Steps to Reproduce:
1. Setup SSSD with multiple domains and add the following in nss section:

command = valgrind -v --log-file=/var/log/sssd/valgrind_nss_%p.log /usr/libexec/sssd/sssd_nss --uid 0 --gid 0 --debug-to-files

Sample sssd.conf file:
----------------------------
[sssd]
domains = sssdad.com, LDAP
config_file_version = 2
services = nss, pam

[nss]
command = valgrind -v --log-file=/var/log/sssd/valgrind_nss_%p.log /usr/libexec/sssd/sssd_nss --uid 0 --gid 0 --debug-to-files

[domain/sssdad.com]
ad_domain = sssdad.com
krb5_realm = SSSDAD.COM
realmd_tags = manages-system joined-with-adcli 
cache_credentials = True
id_provider = ad
krb5_store_password_if_offline = True
default_shell = /bin/bash
ldap_id_mapping = True
use_fully_qualified_names = True
fallback_homedir = /home/%u@%d
access_provider = ad

[domain/LDAP]
id_provider = ldap
auth_provider = ldap
enumerate = true
debug_level = 0xFFF0
cache_credentials = FALSE
ldap_uri = ldaps://<SERVER>
ldap_tls_cacert = /etc/openldap/certs/cacert.asc
ldap_search_base = dc=example,dc=com

2. Set SELinux to permissive mode or else sssd will fail to start.

3. Restart SSSD and run initgroups against user from first domain.

# id testuser OR id --groups testuser

# id --groups GROUP

Actual results:
Verify valgrind log file:

==18031== Invalid read of size 4
==18031==    at 0x52A8928: ??? (in /usr/lib64/libpopt.so.0.0.0)
==18031==    by 0x52A92FA: poptGetNextOpt (in /usr/lib64/libpopt.so.0.0.0)
==18031==    by 0x10DDF0: ??? (in /usr/libexec/sssd/sssd_nss)
==18031==    by 0x8FD9B14: (below main) (libc-start.c:274)
==18031==  Address 0xba6b5e0 is 0 bytes inside a block of size 2 alloc'd
==18031==    at 0x4C29BFD: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==18031==    by 0x52A881E: ??? (in /usr/lib64/libpopt.so.0.0.0)
==18031==    by 0x52A92FA: poptGetNextOpt (in /usr/lib64/libpopt.so.0.0.0)
==18031==    by 0x10DDF0: ??? (in /usr/libexec/sssd/sssd_nss)
==18031==    by 0x8FD9B14: (below main) (libc-start.c:274)

Expected results:
No error.

Additional info:

Comment 2 Daniel Mach 2019-02-14 08:38:09 UTC
I was unable to reproduce the steps on a RHEL 7.6 system.
Restarting sssd failed on:
sssd[320]: Could not create private keyring session. If you store password there they may be easily accessible to the root user. (1, Operation not permitted)
sssd[320]: Could not set permissions on private keyring. If you store password there they may be easily accessible to the root user. (1, Operation not permitted)


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