Bug 693377

Summary: useradd segfaults when UID_MAX >= 2147483647
Product: Red Hat Enterprise Linux 6 Reporter: Eric Sammons <esammons>
Component: shadow-utilsAssignee: Peter Vrabec <pvrabec>
Status: CLOSED ERRATA QA Contact: BaseOS QE Security Team <qe-baseos-security>
Severity: medium Docs Contact:
Priority: medium    
Version: 6.0CC: mvadkert
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-12-06 16:27:49 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
fix candidate none

Description Eric Sammons 2011-04-04 13:47:22 UTC
Description of problem:
When setting UID_MAX >= 2147483647 in login.defs useradd will segfault when adding new users.


Version-Release number of selected component (if applicable):
RHEL 6
shadow-utils-4.1.4.2-8.el6.x86_64


How reproducible:
Every time


Steps to Reproduce:
1. Edit login.defs to have UID_MAX >= 2147483647
   # sed -i 's/^UID_MAX.*$/UID_MAX                 2147483647/' login.defs
2. Add user
   # useradd test
   segfault
  
Actual results:
segfault

Expected results:
Error message or accept values of UID_MAX >= int

Additional info:

Starting program: /usr/sbin/useradd test

Program received signal SIGSEGV, Segmentation fault.
0x0000000000408484 in find_new_uid (sys_user=false, uid=0x6158c8, 
    preferred_uid=0x0) at /usr/include/bits/string3.h:86
warning: Source file is more recent than executable.
86	  return __builtin___memset_chk (__dest, __ch, __len, __bos0 (__dest));
(gdb) bt
#0  0x0000000000408484 in find_new_uid (sys_user=false, uid=0x6158c8, 
    preferred_uid=0x0) at /usr/include/bits/string3.h:86
#1  0x00000000004069be in main (argc=<value optimized out>, 
    argv=<value optimized out>) at useradd.c:1973

Here's the relevant section of code from useradd.c

1968		if (!oflg) {
1969			/* first, seek for a valid uid to use for this user.
1970			 * We do this because later we can use the uid we found as
1971			 * gid too ... --gafton */
1972			if (!uflg) {
1973				if (find_new_uid (rflg, &user_id, NULL) < 0) {
1974					fprintf (stderr, _("%s: can't create user\n"), Prog);
1975					fail_exit (E_UID_IN_USE);
1976				}
1977			} else {

If we look at find_new_uid.c:53
53	{
(gdb) list
48	 * Return 0 on success, -1 if no unused UIDs are available.
49	 */
50	int find_new_uid (bool sys_user,
51	                  uid_t *uid,
52	                  /*@null@*/uid_t const *preferred_uid)
53	{
54		const struct passwd *pwd;
55		uid_t uid_min, uid_max, user_id, id;
56		bool *used_uids;
57	
58		assert (uid != NULL);
59	
60		if (!sys_user) {
61			uid_min = (uid_t) getdef_ulong ("UID_MIN", 500UL);
62			uid_max = (uid_t) getdef_ulong ("UID_MAX", 60000UL);
63		} else {
64			uid_min = (uid_t) getdef_ulong ("SYS_UID_MIN", 201UL);
65			uid_max = (uid_t) getdef_ulong ("UID_MIN", 500UL) - 1;
66			uid_max = (uid_t) getdef_ulong ("SYS_UID_MAX", (unsigned long) uid_max);
67		}

Comment 2 RHEL Program Management 2011-04-04 13:54:46 UTC
Since RHEL 6.1 External Beta has begun, and this bug remains
unresolved, it has been rejected as it is not proposed as
exception or blocker.

Red Hat invites you to ask your support representative to
propose this request, if appropriate and relevant, in the
next release of Red Hat Enterprise Linux.

Comment 3 Peter Vrabec 2011-05-16 20:12:18 UTC
Created attachment 499220 [details]
fix candidate

replace alloca() with malloc() + return valua check

Comment 6 Miroslav Vadkerti 2011-08-10 15:35:56 UTC
The malloc fix somehow fixed the issue. Though I still having trouble to add a user with a seriously big UID. Check this example:

# cat /etc/login.defs | grep UID_MAX
UID_MAX			  214748364700
# useradd -u 21474836470 large
useradd: invalid user ID '21474836470'

I understand adding user with such a big id could be problematic, though

Comment 8 errata-xmlrpc 2011-12-06 16:27:49 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHBA-2011-1650.html