Bug 712158

Summary:	uid/gid overflow in ipcs
Product:	Red Hat Enterprise Linux 6	Reporter:	Mike Gahagan <mgahagan>
Component:	util-linux-ng	Assignee:	Karel Zak <kzak>
Status:	CLOSED ERRATA	QA Contact:	qe-baseos-daemons
Severity:	medium	Docs Contact:
Priority:	medium
Version:	6.1	CC:	azelinka, jburke, jmarko, jstancek, kvolny, rvokal
Target Milestone:	rc
Target Release:	6.2
Hardware:	Unspecified
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2011-12-06 17:11:04 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:

Description Mike Gahagan 2011-06-09 16:08:59 UTC

Description of problem:
After running the iknowthis syscall fuzzer it was observed that a number of shared memory segments and semaphores were created with negative UID values, possibly indicative we have an overflow somewhere. I've only run this on x86_64 under a kvm vm and on an EC2. I'm not certain how reproduceable it is on other architectures.

Version-Release number of selected component (if applicable):
6.0GA kernel (2.6.32-71.el6), also observed on the 6.1 kernel

How reproducible:
very frequently if not always.

Steps to Reproduce:
1.install rh-tests-kernel-syscalls-iknowthis-1.0-5.noarch package
2. optional to save time: edit /mnt/tests/kernel/syscalls/iknowthis/runtest.sh and set the TTL value to 60
3. make run && ipcs -a

  
Actual results:

large numbers of segments owned by the nobody user are expected, in addition there will be some entries like:
[root@test1239 iknowthis]# cat ipcs_corrupted_owner.txt 

------ Shared Memory Segments --------
key        shmid      owner      perms      bytes      nattch     status      
0x00000000 98307      -919909918 71         2219       0                       
0x00000000 458756     -1640302975 770        2198       0                       
0x00000000 360459     -1042436746 511        2381       0                       
0x00000000 557071     2144252550 2          2423       0                       
0x00000000 753684     -646245353 215        1480       0                       
0xc6aacd9d 786453     -585118370 306        1638       0                       
0x00000000 1048598    731723328  111        192        0                       
0x00000000 917529     2063889108 254        244        0                       
0x00000000 1146910    2137292102 124        1884       0                       
0x00000000 1409060    -578934136 517        2946       0                       
0x00000000 1474598    1774147028 322        3284       0                       
0xbefb74d1 1638441    -915158055 460        2395       0                       

------ Semaphore Arrays --------
key        semid      owner      perms      nsems     
0x00000000 0          root       600        1         
0x00000000 65537      root       600        1         
0x00000000 327688     -1812238101 10         9         
0x00000000 491532     -1100133973 173        75        
0x7f2f5fff 524301     1852806226 201        158       
0x00000000 557070     1325148967 663        50        
0x7a764f0f 688146     -237789360 501        201       
0xdf7f0f4b 983067     -192109677 560        145       
0x7d7ef5eb 1015836    403654575  464        38        
0x00000000 1048605    1195741699 706        228       
0x00000000 1736754    -1973206851 744        235       
0x00000000 1933368    403905649  13         145       
0x57f67bfe 3473509    -1087134818 701        154       

------ Message Queues --------
key        msqid      owner      perms      used-bytes   messages    

The large negative values should not be there as UID's. Message queues are unaffected.


Expected results:
no negative values for the owner field.

Additional info:
If you would like to schedule this in beaker, you will need to reserve the system after the test runs to gather the ipcs data at this point.

Comment 1 Mike Gahagan 2011-06-10 18:11:02 UTC

After further investigation, this looks to be a bug in ipcs. If a user with an id > 2147483647 exists in /etc/passwd then we print the user name as expected. If however the user that creates the segment/semaphore/message queue is later deleted from /etc/passwd then we overflow and print a negative value.

[root@test1239 iknowthis]# adduser -u 4294967293 biggeruid
[root@test1239 iknowthis]# su biggeruid -c 'ipcmk -M 1023'
Shared memory id: 3145800
[root@test1239 iknowthis]# ipcs | grep 3145
0x4e8fb57b 3145800    biggeruid  644        1023       0                       
0x808648a4 3145824    nobody     255        0            0           
[root@test1239 iknowthis]# userdel biggeruid
[root@test1239 iknowthis]# ipcs | grep 3145
0x4e8fb57b 3145800    -3         644        1023       0                       
0x808648a4 3145824    nobody     255        0            0           
[root@test1239 iknowthis]# adduser -u 2147483646 biguser32
[root@test1239 iknowthis]# su biguser32 -c 'ipcmk -M 1023'
Shared memory id: 3178569
[root@test1239 iknowthis]# ipcs | grep 3178569
0x5d9692ae 3178569    biguser32  644        1023       0                       
[root@test1239 iknowthis]# userdel biguser32
[root@test1239 iknowthis]# ipcs | grep 3178569
0x5d9692ae 3178569    2147483646 644        1023       0                       
[root@test1239 iknowthis]# adduser -u 2147483648 biggeruser32
[root@test1239 iknowthis]# su biggeruser32 -c 'ipcmk -M 1023'
Shared memory id: 3211338
[root@test1239 iknowthis]# ipcs | grep 3211338
0x703d3943 3211338    biggeruser 644        1023       0                       
[root@test1239 iknowthis]# userdel biggeruser32
[root@test1239 iknowthis]# ipcs | grep 3211338
0x703d3943 3211338    -2147483648 644        1023       0                       
[root@test1239 iknowthis]# adduser -u 4294967297 overflowbiguser32
adduser: invalid user ID '4294967297'

Comment 2 Karel Zak 2011-06-10 22:14:13 UTC

uid_t and gid_t are unsigned types -- unfortunately, ipcs(1) uses %d for the types...

Comment 5 Karel Zak 2011-08-09 13:34:27 UTC

Fixed by upstream commit 344f73442d3a45db5927c049eef1ed8cf5d13934.

Comment 8 errata-xmlrpc 2011-12-06 17:11:04 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/RHSA-2011-1691.html