Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 15 Nov 2024 10:48:57 GMT
From:      Olivier Certner <olce@FreeBSD.org>
To:        src-committers@FreeBSD.org, dev-commits-src-all@FreeBSD.org, dev-commits-src-branches@FreeBSD.org
Subject:   git: e657e1e95062 - stable/14 - cred: 'kern.ngroups' tunable: Limit it to avoid internal overflows
Message-ID:  <202411151048.4AFAmvdJ017951@gitrepo.freebsd.org>

next in thread | raw e-mail | index | archive | help
The branch stable/14 has been updated by olce:

URL: https://cgit.FreeBSD.org/src/commit/?id=e657e1e95062c7d06ac6c5dd128a270a4ac0d72a

commit e657e1e95062c7d06ac6c5dd128a270a4ac0d72a
Author:     Olivier Certner <olce@FreeBSD.org>
AuthorDate: 2024-10-01 17:00:43 +0000
Commit:     Olivier Certner <olce@FreeBSD.org>
CommitDate: 2024-11-15 10:47:42 +0000

    cred: 'kern.ngroups' tunable: Limit it to avoid internal overflows
    
    As the comment introduced with the tunable said (but the code didn't
    do), make sure that 'ngroups_max' can't be INT_MAX, as this would cause
    overflow in the usual 'ngroups_max + 1' computations (as we store the
    effective GID and supplementary groups' IDs in the same array, and
    'ngroups_max' only applies to supplementary groups).
    
    Further, we limit the maximum number of groups somewhat arbitrarily to
    ~17M so as to avoid overflow when computing the size in bytes of the
    groups set's backing array and to avoid obvious configuration errors.
    We really don't think that more than ~17M groups will ever be needed (if
    I'm proven wrong one day, please drop me a note about your use case).
    
    While here, document more precisely why NGROUPS_MAX needs to be the
    minimum value for 'ngroups_max'.
    
    Reviewed by:    mhorne (older version)
    Approved by:    markj (mentor)
    MFC after:      3 days
    Differential Revision:  https://reviews.freebsd.org/D46913
    
    (cherry picked from commit 580904d995d53ccd2492140a37107442d8b36dc0)
    
    Approved by:    markj (mentor)
---
 sys/kern/subr_param.c | 24 +++++++++++++++++++++---
 1 file changed, 21 insertions(+), 3 deletions(-)

diff --git a/sys/kern/subr_param.c b/sys/kern/subr_param.c
index c0a4ac747d00..cee70a842735 100644
--- a/sys/kern/subr_param.c
+++ b/sys/kern/subr_param.c
@@ -229,14 +229,32 @@ init_param1(void)
 	TUNABLE_ULONG_FETCH("kern.sgrowsiz", &sgrowsiz);
 
 	/*
-	 * Let the administrator set {NGROUPS_MAX}, but disallow values
-	 * less than NGROUPS_MAX which would violate POSIX.1-2008 or
-	 * greater than INT_MAX-1 which would result in overflow.
+	 * Let the administrator set {NGROUPS_MAX}.
+	 *
+	 * Values less than NGROUPS_MAX would violate POSIX/SuS (see the
+	 * specification for <limits.h>, paragraph "Runtime Increasable
+	 * Values").
+	 *
+	 * On the other hand, INT_MAX would result in an overflow for the common
+	 * 'ngroups_max + 1' computation (to obtain the size of the internal
+	 * groups array, its first element being reserved for the effective
+	 * GID).  Also, the number of allocated bytes for the group array must
+	 * not overflow on 32-bit machines.  For all these reasons, we limit the
+	 * number of supplementary groups to some very high number that we
+	 * expect will never be reached in all practical uses and ensures we
+	 * avoid the problems just exposed, even if 'gid_t' was to be enlarged
+	 * by a magnitude.
 	 */
 	ngroups_max = NGROUPS_MAX;
 	TUNABLE_INT_FETCH("kern.ngroups", &ngroups_max);
 	if (ngroups_max < NGROUPS_MAX)
 		ngroups_max = NGROUPS_MAX;
+	else {
+		const int ngroups_max_max = (1 << 24) - 1;
+
+		if (ngroups_max > ngroups_max_max)
+			ngroups_max = ngroups_max_max;
+	}
 
 	/*
 	 * Only allow to lower the maximal pid.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?202411151048.4AFAmvdJ017951>