One of the packages I upgraded at the time I noticed the problem was coreutils. In the TODO file under /usr/doc/coreutils-5.94 is the following:
Implement Ulrich Drepper's suggestion to use getgrouplist rather
than getugroups. This affects only `id', but makes a big difference
on systems with many users and/or groups, and makes id usable once
again on systems where access restrictions make getugroups fail.
But first we'll need a run-test (either in an autoconf macro or at
run time) to avoid the segfault bug in libc-2.3.2's getgrouplist.
In that case, we'd revert to using a new (to-be-written) getgrouplist
module that does most of what `id' already does.
I wondered if this was related to the problem so I tried to look up man getugroups
but got nothing. However man getgrouplist
does provide an entry and the man page does list a bug:
The glibc 2.3.2 implementation of this function is broken: it overwrites memory when the actual number
of groups is larger than *ngroups.
Perhaps the problem is related to this - but that's just a guess...