Re: Valgrind warnings for `automount`

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 06/08/17 15:14, Paul Menzel wrote:
Dear autofs folks,


Valgrind 3.12.0 shows the following when running `automount`.

```
==63563== Thread 12:
==63563== Conditional jump or move depends on uninitialised value(s)
==63563==    at 0x4C2E826: rawmemchr (vg_replace_strmem.c:1402)
==63563==    by 0x61D3FB6: _nss_files_parse_grent (fgetgrent_r.c:37)
==63563==    by 0xB3CA5FA: internal_getent (files-XXX.c:272)
==63563==    by 0xB3CA9E0: _nss_files_getgrgid_r (files-grp.c:39)
==63563==    by 0x61D393B: getgrgid_r@@GLIBC_2.2.5 (getXXbyYY_r.c:266)
==63563==    by 0x131AC3: set_tsd_user_vars (mounts.c:1538)
==63563==    by 0x11B652: do_mount_indirect (indirect.c:776)
==63563==    by 0x4E3B190: start_thread (pthread_create.c:309)
==63563==  Uninitialised value was created by a heap allocation
==63563==    at 0x4C27A10: malloc (vg_replace_malloc.c:298)
==63563==    by 0x4C299DC: realloc (vg_replace_malloc.c:785)
==63563==    by 0x131A4D: set_tsd_user_vars (mounts.c:1530)
==63563==    by 0x11B652: do_mount_indirect (indirect.c:776)
==63563==    by 0x4E3B190: start_thread (pthread_create.c:309)
==63563==
==63563== Conditional jump or move depends on uninitialised value(s)
==63563==    at 0x4C2A4A5: __GI_strchr (vg_replace_strmem.c:246)
==63563==    by 0x61D3DBB: _nss_files_parse_grent (fgetgrent_r.c:37)
==63563==    by 0xB3CA5FA: internal_getent (files-XXX.c:272)
==63563==    by 0xB3CA9E0: _nss_files_getgrgid_r (files-grp.c:39)
==63563==    by 0x61D393B: getgrgid_r@@GLIBC_2.2.5 (getXXbyYY_r.c:266)
==63563==    by 0x131AC3: set_tsd_user_vars (mounts.c:1538)
==63563==    by 0x11B652: do_mount_indirect (indirect.c:776)
==63563==    by 0x4E3B190: start_thread (pthread_create.c:309)
==63563==  Uninitialised value was created by a heap allocation
==63563==    at 0x4C27A10: malloc (vg_replace_malloc.c:298)
==63563==    by 0x4C299DC: realloc (vg_replace_malloc.c:785)
==63563==    by 0x131A4D: set_tsd_user_vars (mounts.c:1530)
==63563==    by 0x11B652: do_mount_indirect (indirect.c:776)
==63563==    by 0x4E3B190: start_thread (pthread_create.c:309)
==63563==
==63563== Conditional jump or move depends on uninitialised value(s)
==63563==    at 0x4C2A49A: __GI_strchr (vg_replace_strmem.c:246)
==63563==    by 0x61D3DBB: _nss_files_parse_grent (fgetgrent_r.c:37)
==63563==    by 0xB3CA5FA: internal_getent (files-XXX.c:272)
==63563==    by 0xB3CA9E0: _nss_files_getgrgid_r (files-grp.c:39)
==63563==    by 0x61D393B: getgrgid_r@@GLIBC_2.2.5 (getXXbyYY_r.c:266)
==63563==    by 0x131AC3: set_tsd_user_vars (mounts.c:1538)
==63563==    by 0x11B652: do_mount_indirect (indirect.c:776)
==63563==    by 0x4E3B190: start_thread (pthread_create.c:309)
==63563==  Uninitialised value was created by a heap allocation
==63563==    at 0x4C27A10: malloc (vg_replace_malloc.c:298)
==63563==    by 0x4C299DC: realloc (vg_replace_malloc.c:785)
==63563==    by 0x131A4D: set_tsd_user_vars (mounts.c:1530)
==63563==    by 0x11B652: do_mount_indirect (indirect.c:776)
==63563==    by 0x4E3B190: start_thread (pthread_create.c:309)
==63563==
```

The corresponding code looks like below.

```
        gr_tmp = NULL;
        status = ERANGE;
#ifdef ENABLE_LIMIT_GETGRGID_SIZE
        if (!maxgrpbuf)
                maxgrpbuf = detached_thread_stack_size * 0.9;
#endif

        /* If getting the group name fails go on without it. It's
         * used to set an environment variable for program maps
         * which may or may not use it so it isn't critical to
         * operation.
         */

        tmplen = grplen;
        while (1) {
                char *tmp = realloc(gr_tmp, tmplen + 1);
                if (!tmp) {
error(logopt, "failed to malloc buffer for getgrgid_r");
                        goto no_group;
                }
                gr_tmp = tmp;
                pgr = &gr;
                ppgr = &pgr;
                status = getgrgid_r(gid, pgr, gr_tmp, tmplen, ppgr);
                if (status != ERANGE)
                        break;
                tmplen += grplen;

                /* Don't tempt glibc to alloca() larger than is (likely)
* available on the stack if limit-getgrgid-size is enabled.
                 */
                if (!maxgrpbuf || (tmplen < maxgrpbuf))
                        continue;

                /* Add a message so we know this happened */
debug(logopt, "group buffer allocation would be too large");
                break;
        }
```

Unfortunately, I don’t spot the problem. Do you see it?


Kind regards,

Paul
This is a bug in glibc 2.19, which is fixed in glibc 2.20.

With glibc-2.19 plus commit

https://sourceware.org/git/?p=glibc.git;a=commit;f=nss/nss_files/files-XXX.c;h=ac60763eac3d43b7234dd21286ad3ec3f17957fc

the warning is gone. Although I expect

https://sourceware.org/git/?p=glibc.git;a=commit;f=nss/nss_files/files-XXX.c;h=d7b00f98106a0f1e3d753b135eeb97dfdf6e2e74

which is included in glibc-2.19, to be part of the solution, too.

Donald

--
Donald Buczek
buczek@xxxxxxxxxxxxx
Tel: +49 30 8413 1433

--
To unsubscribe from this list: send the line "unsubscribe autofs" in



[Index of Archives]     [Linux Filesystem Development]     [Linux Ext4]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux