Bug#994102: unistd.h: non-null check not correct for getcwd()
On 2021-09-11 22:06, Jan-Benedict Glaw wrote: > Until glibc's Bugzilla issue is finally resolved > (https://sourceware.org/bugzilla/show_bug.cgi?id=26545), maybe the > Debian package could be changed to drop the access attribute? No. Once we have patched it, we will have to differ from upstream almost forever, and we want to avoid that. I already have sent a patch [1], I am waiting for feedback. Regards, Aurelien [1] https://sourceware.org/pipermail/libc-alpha/2021-September/130886.html -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net signature.asc Description: PGP signature
Re: Bug#994091: nmu: aide_0.17.3-4
On 2021-09-11 21:52, Adrian Bunk wrote: > On Sat, Sep 11, 2021 at 03:59:12PM +0200, Marc Haber wrote: > > Package: release.debian.org > > Severity: normal > > User: release.debian@packages.debian.org > > Usertags: binnmu > > > > [this is my first binNMU request, I hope that I did everything right] > > [ I am not a member of the release team ] > > > aide is statically linked. With the new glibc, NSS calls get somehow > > still some dynamic linking, which causes a reproducible and > > unconditional segfault one aide uses an NSS-releated call. A rebuild > > fixes this issue. I am currently discussing this issue with upstream to > > find out whether we can do things a bit better in the future. > > AFAIR static glibc linking and NSS is known problematic. Indeed, I confirm. Note that this will change with glibc 2.34 which has nss_files and nss_dns built-in. > The dependencies should ensure that apt/dpkg only install a working set > of packages. Dependencies like "libc6 (>> 2.32), libc6 (<< 2.33)" might > help, but I've added debian-glibc to Cc since I don't know for sure > whether this would be sufficient. This is correct, there is no breakage between minor version, only between major version. Now, given that bookworm will very likely have glibc >= 2.34 (at least that the goal if we are able to solve all issues with each new upstream version), so I am not sure if it is worth implementing such a change. Regards, Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
Processed: forcibly merging 993973 994102
Processing commands for cont...@bugs.debian.org: > forcemerge 993973 994102 Bug #993973 [libc6-dev] nss FTBFS with glibc 2.32: error: argument 1 is null but the corresponding size argument 2 value is 4096 [-Werror=nonnull] Bug #994102 [libc6-dev] unistd.h: non-null check not correct for getcwd() Set Bug forwarded-to-address to 'https://sourceware.org/bugzilla/show_bug.cgi?id=27476'. Severity set to 'serious' from 'normal' Added indication that 994102 affects src:nss Marked as found in versions glibc/2.32-1. Added tag(s) ftbfs. Bug #993973 [libc6-dev] nss FTBFS with glibc 2.32: error: argument 1 is null but the corresponding size argument 2 value is 4096 [-Werror=nonnull] Marked as found in versions glibc/2.32-2. Merged 993973 994102 > thanks Stopping processing here. Please contact me if you need assistance. -- 993973: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=993973 994102: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=994102 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#994102: unistd.h: non-null check not correct for getcwd()
Package: libc6-dev Version: 2.32-2 Current getcwd() is declared as: /usr/include/unistd.h: 513:/* Get the pathname of the current working directory, 514: and put it in SIZE bytes of BUF. Returns NULL if the 515: directory couldn't be determined or SIZE was too small. 516: If successful, returns BUF. In GNU, if BUF is NULL, 517: an array is allocated with `malloc'; the array is SIZE 518: bytes long, unless SIZE == 0, in which case it is as 519: big as necessary. */ 520:extern char *getcwd (char *__buf, size_t __size) __THROW __wur 521:__attr_access ((__write_only__, 1, 2)); Documentation (man page) states: As an extension to the POSIX.1-2001 standard, glibc's getcwd() allo- cates the buffer dynamically using malloc(3) if buf is NULL. In this case, the allocated buffer has the length size unless size is zero, when buf is allocated as big as necessary. The caller should free(3) the returned buffer. The current check doesn't accept the NULL pointer with recent GCC versions and breaks, for example, building GCC from sources due to fixincl.c using NULL as the buffer argument so it doesn't need to allocate on its own: [all 2021-09-11 18:34:38] make[1]: Entering directory '/var/lib/laminar/run/gcc-bfin-elf/6/toolchain-build/build-x86_64-pc-linux-gnu/fixincludes' [all 2021-09-11 18:34:38] /usr/lib/gcc-snapshot/bin/gcc -c -g -O2 -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wmissing-format-attribute -Wno-overlength-strings -pedantic -Wno-long-long -Werror -DHAVE_CONFIG_H -I. -I../../../gcc/fixincludes -I../include -I../../../gcc/fixincludes/../include ../../../gcc/fixincludes/fixincl.c [all 2021-09-11 18:34:39] ../../../gcc/fixincludes/fixincl.c: In function 'process': [all 2021-09-11 18:34:39] ../../../gcc/fixincludes/fixincl.c:1356:7: error: argument 1 is null but the corresponding size argument 2 value is 4096 [-Werror=nonnull] [all 2021-09-11 18:34:39] 1356 | fprintf (stderr, "Cannot access %s from %s\n\terror %d (%s)\n", [all 2021-09-11 18:34:39] | ^~~ [all 2021-09-11 18:34:39] 1357 |pz_curr_file, getcwd ((char *) NULL, MAXPATHLEN), [all 2021-09-11 18:34:39] | ~ [all 2021-09-11 18:34:39] 1358 |erno, xstrerror (erno)); [all 2021-09-11 18:34:39] |~~~ [all 2021-09-11 18:34:39] In file included from ../../../gcc/fixincludes/system.h:192, [all 2021-09-11 18:34:39] from ../../../gcc/fixincludes/fixlib.h:29, [all 2021-09-11 18:34:39] from ../../../gcc/fixincludes/fixincl.c:24: [all 2021-09-11 18:34:39] /usr/include/unistd.h:520:14: note: in a call to function 'getcwd' declared with attribute 'access (write_only, 1, 2)' [all 2021-09-11 18:34:39] 520 | extern char *getcwd (char *__buf, size_t __size) __THROW __wur [all 2021-09-11 18:34:39] | ^~ [all 2021-09-11 18:34:39] cc1: all warnings being treated as errors [all 2021-09-11 18:34:39] make[1]: *** [Makefile:76: fixincl.o] Error 1 [all 2021-09-11 18:34:39] make[1]: Leaving directory '/var/lib/laminar/run/gcc-bfin-elf/6/toolchain-build/build-x86_64-pc-linux-gnu/fixincludes' [all 2021-09-11 18:34:39] make: *** [Makefile:2854: all-build-fixincludes] Error 2 (That's from a not-yet publically announced auto-builder that does build GCC/Binutils, Linux Kernel, NetBSD and SIMH to check for them being buildable for a good number of configurations.) For comparison, with libc6-dev at 2.31-16, declaration was like this: 504:/* Get the pathname of the current working directory, 505: and put it in SIZE bytes of BUF. Returns NULL if the 506: directory couldn't be determined or SIZE was too small. 507: If successful, returns BUF. In GNU, if BUF is NULL, 508: an array is allocated with `malloc'; the array is SIZE 509: bytes long, unless SIZE == 0, in which case it is as 510: big as necessary. */ 511:extern char *getcwd (char *__buf, size_t __size) __THROW __wur; Until glibc's Bugzilla issue is finally resolved (https://sourceware.org/bugzilla/show_bug.cgi?id=26545), maybe the Debian package could be changed to drop the access attribute? Thanks, Jan-Benedict -- signature.asc Description: PGP signature
Re: Bug#994091: nmu: aide_0.17.3-4
On Sat, Sep 11, 2021 at 03:59:12PM +0200, Marc Haber wrote: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: binnmu > > [this is my first binNMU request, I hope that I did everything right] [ I am not a member of the release team ] > aide is statically linked. With the new glibc, NSS calls get somehow > still some dynamic linking, which causes a reproducible and > unconditional segfault one aide uses an NSS-releated call. A rebuild > fixes this issue. I am currently discussing this issue with upstream to > find out whether we can do things a bit better in the future. AFAIR static glibc linking and NSS is known problematic. > Greetings > Marc > > > nmu aide_0.17.3-4 . ANY . unstable . -m "Rebuild against the new glibc" The dependencies should ensure that apt/dpkg only install a working set of packages. Dependencies like "libc6 (>> 2.32), libc6 (<< 2.33)" might help, but I've added debian-glibc to Cc since I don't know for sure whether this would be sufficient. cu Adrian
