crcopysafe() attempts to crextend() the new ucred's groups up to the allocation to
size offit all of the groups from the old ucred's, but for certain values of ngroups_max we can
ngroups_max we can end up with a larger-than-max cr_asize as crextend() rounds up the
rounds up the allocation to the next power-of-2.
This was not a problem before be1f7435ef218b1 because the effective max
storage was NGROUPS_MAX + 1 (1024) to account for the egid being
included in cr_groups. Now that we're back down to NGROUPS_MAX, the max
allocation will tend to be 1024 and exceed our max groups.
Note at the point where we clamp sc_agroups that it can be a problem if
we decide to make this runtime tunable later, but I don't really
Switch crcopysafe() to extend until we have enough allocated to fit
foresee that happening. This allows us to keepthe previous group set, and call crextend() with the loop in crcopysafe()number of groups
a bit cleaner, since it otherwise probably should clamp both oldcred andthat the old ucred had. This avoids relying on implementation details
newcred to avoid makof crextend() up-sizing assumptions about how crextend() will allocateour requests and ensures we only have as large
at ngrps == ngroups_max.
Fixes: be1f7435ef218b1 ("kern: start tracking cr_gid outside [...]")of an allocation as we need to fulfill the request.
Reported by: syzbot+4e68da43c26f357a2b7e@syzkaller.appspotmail.com