useradd aborts in 4.9

[dm0-]

When I try to add a user in a prefix, I get this:

free(): invalid pointer

Program received signal SIGABRT, Aborted.
0x00007ffff7e20d11 in raise () from /lib64/libc.so.6
(gdb) bt
#0  0x00007ffff7e20d11 in raise () from /lib64/libc.so.6
#1  0x00007ffff7e0a538 in abort () from /lib64/libc.so.6
#2  0x00007ffff7e62a07 in ?? () from /lib64/libc.so.6
#3  0x00007ffff7e6a4bc in ?? () from /lib64/libc.so.6
#4  0x00007ffff7e6b894 in ?? () from /lib64/libc.so.6
#5  0x00007ffff7e6f554 in free () from /lib64/libc.so.6
#6  0x0000555555566279 in gr_free (grent=0x7ffff7fa23a0) at groupmem.c:107
#7  0x000055555555c492 in get_defaults () at useradd.c:418
#8  0x0000555555559b7e in main (argc=7, argv=0x7fffffffe2a8) at useradd.c:2451

It happens when freeing the default group entry, which is GROUP=100 corresponding to the line users::100: in this case. (The specific free call that fails is for gr_passwd which is "", but I don't think that's relevant. It fails in the same place with different passwd values.) The group being freed is returned from prefix_getgr_nam_gid, which seems to just be returned from fgetgrent.

According to glibc documentation, the return value of fgetgrent is statically allocated, so it should not be freed.

[hallyn]

Thanks. Yeah, unfortunately in some cases it will be a free-able value (in particular in getgr_nam_gid path).

Since useradd always exits and is not a library, "memory leaks" are not really worth worrying about, so I'll revert c44b71c which introduced this.

Thanks for reporting this.