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: #000006908 in rpl_free () at ../lib/free.c:48 #100007133 in free_dir (=93825030210688) at ../lib/fts-cycle.c:159 #200006886 in rpl_fts_close (=93825030210688) at ../lib/fts.c:624 #300005835 in rm (=93825049567272, =93825049567520) at ../src/remove.c:640 #400005469 in __klee_posix_wrapped_main (=2, =93825049567264) at ../src/rm.c:366 #500003474 in __user_main (=15, =93825033594992, =93825033595120) at runtime/POSIX/klee_init_env.c:252 #600000686 in __uClibc_main (=15, =93825033594992) at libc/misc/internals/__uClibc_main.c:401 #700000852 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 <egg...@cs.ucla.edu> 于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 > >
