Bug 1394704

Summary:	Conditional jump or move depends on uninitialised value in setmntent(3)
Product:	Red Hat Enterprise Linux 6	Reporter:	Branislav Blaškovič <bblaskov>
Component:	glibc	Assignee:	glibc team <glibc-bugzilla>
Status:	CLOSED DUPLICATE	QA Contact:	qe-baseos-tools-bugs
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	6.8	CC:	ashankar, fweimer, mnewsome, pfrankli, ppisar
Target Milestone:	rc
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2017-04-03 08:42:43 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:

Description Branislav Blaškovič 2016-11-14 09:44:43 UTC

Description of problem:
There are errors when running quota via valgrind which were not there in older versions.

Version-Release number of selected component (if applicable):
quota-3.17-23.el6

Steps to Reproduce:
1. Run test /CoreOS/quota/Regression/bz684017-memory-leak

Actual results:
==2504== Conditional jump or move depends on uninitialised value(s)
==2504==    at 0x4EA2849: _IO_file_fopen@@GLIBC_2.2.5 (in /lib64/libc-2.12.so)
==2504==    by 0x4E96D95: __fopen_internal (in /lib64/libc-2.12.so)
==2504==    by 0x4F12C83: setmntent (in /lib64/libc-2.12.so)
==2504==    by 0x11099A: cache_mnt_table (quotasys.c:992)
==2504==    by 0x111221: init_mounts_scan (quotasys.c:1263)
==2504==    by 0x1113F2: create_handle_list (quotasys.c:717)
==2504==    by 0x10B0A4: showquotas (quota.c:132)
==2504==    by 0x10BB6B: main (quota.c:340)
==2504== 
==2504== Conditional jump or move depends on uninitialised value(s)
==2504==    at 0x4EA284F: _IO_file_fopen@@GLIBC_2.2.5 (in /lib64/libc-2.12.so)
==2504==    by 0x4E96D95: __fopen_internal (in /lib64/libc-2.12.so)
==2504==    by 0x4F12C83: setmntent (in /lib64/libc-2.12.so)
==2504==    by 0x11099A: cache_mnt_table (quotasys.c:992)
==2504==    by 0x111221: init_mounts_scan (quotasys.c:1263)
==2504==    by 0x1113F2: create_handle_list (quotasys.c:717)
==2504==    by 0x10B0A4: showquotas (quota.c:132)
==2504==    by 0x10BB6B: main (quota.c:340)
==2504== 
==2504== Conditional jump or move depends on uninitialised value(s)
==2504==    at 0x4EA2854: _IO_file_fopen@@GLIBC_2.2.5 (in /lib64/libc-2.12.so)
==2504==    by 0x4E96D95: __fopen_internal (in /lib64/libc-2.12.so)
==2504==    by 0x4F12C83: setmntent (in /lib64/libc-2.12.so)
==2504==    by 0x11099A: cache_mnt_table (quotasys.c:992)
==2504==    by 0x111221: init_mounts_scan (quotasys.c:1263)
==2504==    by 0x1113F2: create_handle_list (quotasys.c:717)
==2504==    by 0x10B0A4: showquotas (quota.c:132)
==2504==    by 0x10BB6B: main (quota.c:340)
==2504== 
==2504== Conditional jump or move depends on uninitialised value(s)
==2504==    at 0x4EA2860: _IO_file_fopen@@GLIBC_2.2.5 (in /lib64/libc-2.12.so)
==2504==    by 0x4E96D95: __fopen_internal (in /lib64/libc-2.12.so)
==2504==    by 0x4F12C83: setmntent (in /lib64/libc-2.12.so)
==2504==    by 0x11099A: cache_mnt_table (quotasys.c:992)
==2504==    by 0x111221: init_mounts_scan (quotasys.c:1263)
==2504==    by 0x1113F2: create_handle_list (quotasys.c:717)
==2504==    by 0x10B0A4: showquotas (quota.c:132)
==2504==    by 0x10BB6B: main (quota.c:340)
==2504== 
==2504== Conditional jump or move depends on uninitialised value(s)
==2504==    at 0x4EA2868: _IO_file_fopen@@GLIBC_2.2.5 (in /lib64/libc-2.12.so)
==2504==    by 0x4E96D95: __fopen_internal (in /lib64/libc-2.12.so)
==2504==    by 0x4F12C83: setmntent (in /lib64/libc-2.12.so)
==2504==    by 0x11099A: cache_mnt_table (quotasys.c:992)
==2504==    by 0x111221: init_mounts_scan (quotasys.c:1263)
==2504==    by 0x1113F2: create_handle_list (quotasys.c:717)
==2504==    by 0x10B0A4: showquotas (quota.c:132)
==2504==    by 0x10BB6B: main (quota.c:340)
==2504== 
==2504== Conditional jump or move depends on uninitialised value(s)
==2504==    at 0x4EBEA13: __GI_strstr (in /lib64/libc-2.12.so)
==2504==    by 0x4EA29A6: _IO_file_fopen@@GLIBC_2.2.5 (in /lib64/libc-2.12.so)
==2504==    by 0x4E96D95: __fopen_internal (in /lib64/libc-2.12.so)
==2504==    by 0x4F12C83: setmntent (in /lib64/libc-2.12.so)
==2504==    by 0x11099A: cache_mnt_table (quotasys.c:992)
==2504==    by 0x111221: init_mounts_scan (quotasys.c:1263)
==2504==    by 0x1113F2: create_handle_list (quotasys.c:717)
==2504==    by 0x10B0A4: showquotas (quota.c:132)
==2504==    by 0x10BB6B: main (quota.c:340)
==2504== 
Disk quotas for user root (uid 0): none
==2504== 
==2504== HEAP SUMMARY:
==2504==     in use at exit: 2,048 bytes in 1 blocks
==2504==   total heap usage: 181 allocs, 180 frees, 34,065 bytes allocated
==2504== 
==2504== LEAK SUMMARY:
==2504==    definitely lost: 0 bytes in 0 blocks
==2504==    indirectly lost: 0 bytes in 0 blocks
==2504==      possibly lost: 0 bytes in 0 blocks
==2504==    still reachable: 2,048 bytes in 1 blocks
==2504==         suppressed: 0 bytes in 0 blocks
==2504== Reachable blocks (those to which a pointer was found) are not shown.
==2504== To see them, rerun with: --leak-check=full --show-reachable=yes


Expected results:
No errors.

Comment 1 Branislav Blaškovič 2016-11-14 09:46:59 UTC

It works fine on RHEL-6.8.
Bug is reproducible on RHEL-6.9-20161110.2.

Weird is, that there are the same quota versions, so I assume that the bug could be in glibc maybe?

Comment 2 Petr Pisar 2016-11-14 10:31:32 UTC

Yes this is an issue in glibc. The quota's code is:

  mntf = setmntent("/proc/mounts", "r");

The mntf is a FILE* pointer.

I can reproduce it with glibc-2.12-1.208.el6.x86_64 and valgrind-3.8.1-8.el6.x86_64 running:

# valgrind quota -f /

There is no need for any file system with enabled or set quotas.

Comment 3 Petr Pisar 2016-11-14 10:35:11 UTC

C reproducer:

#include <stdlib.h>
#include <stdio.h>
#include <mntent.h>

int main(void) {
        FILE *mntf;
        mntf = setmntent("/proc/mounts", "r");
        if (mntf) {
                endmntent(mntf);
        }
        exit(EXIT_SUCCESS);
}

Comment 8 Florian Weimer 2017-04-03 08:42:43 UTC


*** This bug has been marked as a duplicate of bug 1437147 ***