This is the mail archive of the
mailing list for the glibc project.
Re: [PATCH] nss_files: Fix /etc/aliases null pointer dereference [BZ #24059]
* Szabolcs Nagy:
> On 01/02/2019 15:15, Florian Weimer wrote:
>> * Szabolcs Nagy:
>>> On 15/01/2019 15:54, Florian Weimer wrote:
>>>> If /etc/aliases ends with a continuation line (a line that starts
>>>> with whitespace) which does not have a training newline character,
>>>> the file parser would crash due to a null pointer dereference.
>>>> 2019-01-15 Florian Weimer <email@example.com>
>>>> [BZ #24059]
>>>> * nss/nss_files/files-alias.c (get_next_alias): Handle
>>>> continuation line without newline at the end.
>>>> * nss/tst-nss-files-alias-truncated.c: New file.
>>>> * nss/Makefile [$(build-shared)] (tests): Add
>>>> (tst-nss-files-alias-truncated): Link with libnss_files.so.
>>>> * support/namespace.h (struct support_chroot_configuration): Add
>>>> aliases member.
>>>> (struct support_chroot): Add path_aliases member.
>>>> * support/support_chroot.c (support_chroot_create): Handle
>>>> (support_chroot_free): Free path_aliases.
>>> aarch64 buildbot consistently fails with
>>> FAIL: nss/tst-nss-files-alias-truncated
>>> error: tst-nss-files-alias-truncated.c:34: not true: e != NULL
>>> error: support_isolate_in_subprocess.c:37: child process exited with status 256
>>> error: 2 test failures
>>> i'm not yet sure why (passes with ./testrun.sh)
>> I haven't seen that, and I don't know what could be causing it. I fear
>> you have to debug it in the context of the build bot, sorry.
> libnss_files.so.2 is not listed as explicit dependency
> for some reason so it is not loaded at program startup,
> but after chroot is entered, but it's not available in
> the chroot so the first api call fails.
There's already this in nss/Makefile:
I expected this causes a DT_NEEDED entry to be added to the executable,
so it is loaded upon startup, outside of the chroot.