bug#65294: [PATCH] maint: Fix compilation error on GNU/Hurd
On 14/08/2023 20:02, Bruno Haible wrote: Compiling a current coreutils on Debian GNU/Hurd from 2022, I get this compilation error: CC src/copy.o ../src/copy.c: In function 'set_author': ../src/copy.c:984:15: error: 'MACH_PORT_nullptr' undeclared (first use in this function); did you mean 'MACH_PORT_NULL'? 984 | if (file == MACH_PORT_nullptr) | ^ | MACH_PORT_NULL ../src/copy.c:984:15: note: each undeclared identifier is reported only once for each function it appears in make[2]: *** [Makefile:12489: src/copy.o] Error 1 The attached patch fixes it. Pushed. thanks, Pádraig
bug#65294: [PATCH] maint: Fix compilation error on GNU/Hurd
Compiling a current coreutils on Debian GNU/Hurd from 2022, I get this
compilation error:
CC src/copy.o
../src/copy.c: In function 'set_author':
../src/copy.c:984:15: error: 'MACH_PORT_nullptr' undeclared (first use in this
function); did you mean 'MACH_PORT_NULL'?
984 | if (file == MACH_PORT_nullptr)
| ^
| MACH_PORT_NULL
../src/copy.c:984:15: note: each undeclared identifier is reported only once
for each function it appears in
make[2]: *** [Makefile:12489: src/copy.o] Error 1
The attached patch fixes it.
>From 2046827462094dde4ac8391865a3edc74e313126 Mon Sep 17 00:00:00 2001
From: Bruno Haible
Date: Mon, 14 Aug 2023 20:59:41 +0200
Subject: [PATCH] maint: Fix compilation error on GNU/Hurd (regression
2023-06-29)
* src/copy.c (set_author): Revert change from MACH_PORT_NULL to
MACH_PORT_nullptr.
---
src/copy.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/copy.c b/src/copy.c
index 90eebf6bc..a4aad06a8 100644
--- a/src/copy.c
+++ b/src/copy.c
@@ -981,7 +981,7 @@ set_author (char const *dst_name, int dest_desc, const struct stat *src_sb)
file_t file = (dest_desc < 0
? file_name_lookup (dst_name, 0, 0)
: getdport (dest_desc));
- if (file == MACH_PORT_nullptr)
+ if (file == MACH_PORT_NULL)
error (0, errno, _("failed to lookup file %s"), quoteaf (dst_name));
else
{
--
2.34.1
bug#65276: Build failure with gcc < 4.8
On 14/08/2023 00:46, Bruno Haible wrote:
Building the current coreutils on GNU/kFreeBSD 7, I get link errors:
CCLD src/cksum
src/cksum-cksum.o: In function `pclmul_supported':
/home/bruno/coreutils-2023-08-13/build-64/../src/cksum.c:149: undefined
reference to `__builtin_cpu_supports'
/home/bruno/coreutils-2023-08-13/build-64/../src/cksum.c:150: undefined
reference to `__builtin_cpu_supports'
collect2: error: ld returned 1 exit status
make[2]: *** [src/cksum] Error 1
CCLD src/wc
src/wc.o: In function `avx2_supported':
/home/bruno/coreutils-2023-08-13/build-64/../src/wc.c:150: undefined reference
to `__builtin_cpu_supports'
collect2: error: ld returned 1 exit status
make[2]: *** [src/wc] Error 1
The reason is that the __builtin_cpu_supports function does not exist
(since the gcc version is 4.7.2 and __builtin_cpu_supports was only
introduced in gcc 4.8), but the configure test succeeds: Compiling this file
=== foo.c ===
#include
int
main (void)
{
return __builtin_cpu_supports ("pclmul");
}
=
merely produces warnings:
$ gcc -c -Wall foo.c
foo.c: In function ‘main’:
foo.c:6:3: warning: implicit declaration of function ‘__builtin_cpu_supports’
[-Wimplicit-function-declaration]
The attached patch fixes it.
Pushed,
thanks,
Pádraig
bug#65269: Fwd: bug#65269: Possible null pointer dereference on the function cycle_check in rm
Just realized I need to send it to this email. Thanks. -- Forwarded message - 发件人： Haoxin Tu Date: 2023年8月14日周一 15:05 Subject: Re: bug#65269: Possible null pointer dereference on the function cycle_check in rm To: Paul Eggert Cc: <65269-d...@debbugs.gnu.org> Hi Paul, Thanks for your quick response. I have tested the latest git version of coreutils again and it seems the bug I reported was gone. However, I found another new *invalid-free *issue which may be induced by the incomplete fix. Please check the bug details below. Here is the stack info reported by our tool: ``` Stack: #06908 in rpl_free () at ../lib/free.c:48 #17133 in free_dir (=93825030210688) at ../lib/fts-cycle.c:159 #26886 in rpl_fts_close (=93825030210688) at ../lib/fts.c:624 #35835 in rm (=93825049567272, =93825049567520) at ../src/remove.c:640 #45469 in __klee_posix_wrapped_main (=2, =93825049567264) at ../src/rm.c:366 #53474 in __user_main (=15, =93825033594992, =93825033595120) at runtime/POSIX/klee_init_env.c:252 #60686 in __uClibc_main (=15, =93825033594992) at libc/misc/internals/__uClibc_main.c:401 #70852 in main (=15, =93825033594992) ``` The root cause is that if the function `fts_read` get a return value of NULL and the malloc from `fts->fts_cycle.state = malloc (sizeof *fts->fts_cycle.state)` (Line 62 in fts_cycle.c) is NULL, the pointer `fts->fts_cycle.state` will still keep 0 before the free operation `free (sp->fts_cycle.state);` (Line 159 in fts_cycle.c), leading to free of invalid address. So, I think the fixing in the patch https://git.savannah.gnu.org/cgit/gnulib.git/commit/?id=f17d397771164c1b0f77fea8fb0abdc99cf4a3e1 did not fully solve the potential issue caused by the improper null pointer checking from the `fts->fts_cycle.state = malloc (sizeof *fts->fts_cycle.state)`. Could you please check again and let me know if I misunderstood anything? Thanks. Best regards, Haoxin Paul Eggert 于2023年8月14日周一 01:29写道： > On 2023-08-13 02:32, Haoxin Tu wrote: > > > We have developed a new tool built on top of KLEE ( > http://klee.github.io/) > > to > > automatically test GNU Coreutils-9.0 and found there might be a possible > > null pointer > > dereference > > Thanks, but this bug was fixed in coreutils 9.2 (2023-03-20), due to > this patch: > > > https://git.savannah.gnu.org/cgit/gnulib.git/commit/?id=f17d397771164c1b0f77fea8fb0abdc99cf4a3e1 > > I suggest using your tool on the latest release, coreutils 9.3. Or even > better you can test the coreutils bleeding edge, by executing these > shell commands, as described in the README-hacking file: > >git clone https://git.savannah.gnu.org/git/coreutils.git >cd coreutils >./bootstrap >./configure >make > >
bug#65269: Possible null pointer dereference on the function cycle_check in rm
Hi Paul, Thanks for your quick response. I have tested the latest git version of coreutils again and it seems the bug I reported was gone. However, I found another new *invalid-free *issue which may be induced by the incomplete fix. Please check the bug details below. Here is the stack info reported by our tool: ``` Stack: #06908 in rpl_free () at ../lib/free.c:48 #17133 in free_dir (=93825030210688) at ../lib/fts-cycle.c:159 #26886 in rpl_fts_close (=93825030210688) at ../lib/fts.c:624 #35835 in rm (=93825049567272, =93825049567520) at ../src/remove.c:640 #45469 in __klee_posix_wrapped_main (=2, =93825049567264) at ../src/rm.c:366 #53474 in __user_main (=15, =93825033594992, =93825033595120) at runtime/POSIX/klee_init_env.c:252 #60686 in __uClibc_main (=15, =93825033594992) at libc/misc/internals/__uClibc_main.c:401 #70852 in main (=15, =93825033594992) ``` The root cause is that if the function `fts_read` get a return value of NULL and the malloc from `fts->fts_cycle.state = malloc (sizeof *fts->fts_cycle.state)` (Line 62 in fts_cycle.c) is NULL, the pointer `fts->fts_cycle.state` will still keep 0 before the free operation `free (sp->fts_cycle.state);` (Line 159 in fts_cycle.c), leading to free of invalid address. So, I think the fixing in the patch https://git.savannah.gnu.org/cgit/gnulib.git/commit/?id=f17d397771164c1b0f77fea8fb0abdc99cf4a3e1 did not fully solve the potential issue caused by the improper null pointer checking from the `fts->fts_cycle.state = malloc (sizeof *fts->fts_cycle.state)`. Could you please check again and let me know if I misunderstood anything? Thanks. Best regards, Haoxin Paul Eggert 于2023年8月14日周一 01:29写道： > On 2023-08-13 02:32, Haoxin Tu wrote: > > > We have developed a new tool built on top of KLEE ( > http://klee.github.io/) > > to > > automatically test GNU Coreutils-9.0 and found there might be a possible > > null pointer > > dereference > > Thanks, but this bug was fixed in coreutils 9.2 (2023-03-20), due to > this patch: > > > https://git.savannah.gnu.org/cgit/gnulib.git/commit/?id=f17d397771164c1b0f77fea8fb0abdc99cf4a3e1 > > I suggest using your tool on the latest release, coreutils 9.3. Or even > better you can test the coreutils bleeding edge, by executing these > shell commands, as described in the README-hacking file: > >git clone https://git.savannah.gnu.org/git/coreutils.git >cd coreutils >./bootstrap >./configure >make > >
