pw useradd has a race between checking if the username is already in use and updating the pw database:
getpwnam check <https://svnweb.freebsd.org/base/head/usr.sbin/pw/pw_user.c?revision=267970&view=markup#l602>
addpwent <https://svnweb.freebsd.org/base/head/usr.sbin/pw/pw_user.c?revision=267970&view=markup#l712> with useless return value check
pw_update without check or nonzero return inside of lock <https://svnweb.freebsd.org/base/head/usr.sbin/pw/pwupd.c?revision=267670&view=markup#l126>
pw groupadd has a race between checking if the groupname is already in use and updating the gr database:
getgrnam check <https://svnweb.freebsd.org/base/head/usr.sbin/pw/pw_group.c?revision=262864&view=markup#l102>
addgrent <https://svnweb.freebsd.org/base/head/usr.sbin/pw/pw_group.c?revision=262864&view=markup#l260> with useless return value check
gr_update without check or nonzero return inside of lock
This race is exhibited when multiple processes attempt to use the error return code of useradd/groupadd to indicate whether they have successfully created a unique user for themselves. If the race occurs, the uid/gid of the database entry may change out from under the first successful process as the second process finds an unused uid/gid and then updates the database using the same key (but the new uid/gid).
I don't believe this bug is a security vulnerability except in contexts where attackers may have control over user/group creation by applications assuming that the database locks ensure non-collision.
pw useradd/groupadd should either consistently let the operator overwrite existing groups/users or should consistently produce a name collision error
pw groupadd/useradd sometimes exits due to a name collision and sometimes overwrites existing groups/users
Not only that, pw is racy in general w.r.t other operations.
An acceptable way around this would be to have a lock (say, /etc/.pw.lock) which is taken at the beginning and released at the end. Preferably also supported by other tools playing with passwd (and other files).