Change Details

crcopysafe() attempts to crextend() the new ucred's groups up to the size of the old ucred's, but for certain values of ngroups_max we can end up with a larger-than-max cr_asize as crextend() 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 foresee that happening. This allows us to keep the loop in crcopysafe() a bit cleaner, since it otherwise probably should clamp both oldcred and newcred to avoid making assumptions about how crextend() will allocate at ngrps == ngroups_max. Fixes: be1f7435ef218b1 ("kern: start tracking cr_gid outside [...]") Reported by: syzbot+4e68da43c26f357a2b7e@syzkaller.appspotmail.com

crcopysafe() attempts to crextend() the new ucred's group allocation to fit all of the groups from the old ucred, but for certain values of ngroups_max we can end up with a larger-than-max cr_asize as crextend() 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. Switch crcopysafe() to extend until we have enough allocated to fit the previous group set, and call crextend() with the number of groups that the old ucred had. This avoids relying on implementation details of crextend() up-sizing our requests and ensures we only have as large of an allocation as we need to fulfill the request.

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