This is the mail archive of the libc-alpha@sources.redhat.com mailing list for the glibc project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
Hi! I was asked to forward this bug report here. Please excuse my strong wording at the end, it took me really a while to see that this *might* not be a Samba problem... Volker ----- Forwarded message from Volker Lendecke <Volker.Lendecke@SerNet.DE> ----- Date: Fri, 27 Jun 2003 17:47:17 +0200 From: Volker Lendecke <Volker.Lendecke@SerNet.DE> To: samba-technical@samba.org Subject: glibc 2.2.5 and 2.3.2 getgrouplist broken? Sender: Volker Lendecke <vlendec@sernet.de> Hi! I've just tried to chase down a segfault in Samba. The Realloc in auth_util.c:670 segfaulted for a customer of mine on a glibc system. The problem is that he had a user with 39 groups in /etc/group imported via winbind. Ok, this is too much, but at least we should not segfault. But it's not samba's fault: It's the libc's getgrouplist function. The following is the code from the debian libc6 2.2.5 source package for getgrouplist: /* Store at most *NGROUPS members of the group set for USER into *GROUPS. Also include GROUP. The actual number of groups found is returned in *NGROUPS. Return -1 if the if *NGROUPS is too small. */ int getgrouplist (const char *user, gid_t group, gid_t *groups, int *ngroups) { gid_t *newgroups; long int size = *ngroups; int result; newgroups = (gid_t *) malloc (size * sizeof (gid_t)); if (__builtin_expect (newgroups == NULL, 0)) /* No more memory. */ return -1; result = internal_getgrouplist (user, group, &size, &newgroups, -1); if (result > *ngroups) { *ngroups = result; result = -1; } else *ngroups = result; memcpy (groups, newgroups, *ngroups * sizeof (gid_t)); free (newgroups); return result; } The memcpy simply assumes to have room in the "groups" array for anything that it finds in /etc/group. We allocate NGROUPS_MAX for the array and hand that to libc which then happily overwrites past the end of the array. To me this does not really look usable. BTW, the code in glibc-2.3.2 looks exactly the same. So what do you think about never using that crap? Volker ----- End forwarded message -----
Attachment:
pgp00000.pgp
Description: PGP signature
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |