712158 – uid/gid overflow in ipcs

RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.

Bug 712158 - uid/gid overflow in ipcs

Summary: uid/gid overflow in ipcs

Keywords:
Status:	CLOSED ERRATA
Alias:	None
Product:	Red Hat Enterprise Linux 6
Classification:	Red Hat
Component:	util-linux-ng
Sub Component:
Version:	6.1
Hardware:	Unspecified
OS:	Linux
Priority:	medium
Severity:	medium
Target Milestone:	rc
Target Release:	6.2
Assignee:	Karel Zak
QA Contact:	qe-baseos-daemons
Docs Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+	depends on / blocked

Reported:	2011-06-09 16:08 UTC by Mike Gahagan
Modified:	2018-11-05 13:29 UTC (History)
CC List:	6 users (show)
Fixed In Version:
Doc Type:	Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed:	2011-12-06 17:11:04 UTC
Target Upstream Version:
Embargoed:

Attachments	(Terms of Use)

Links
System	ID	Private	Priority	Status	Summary	Last Updated
Red Hat Product Errata	RHSA-2011:1691	0	normal	SHIPPED_LIVE	Low: util-linux-ng security, bug fix, and enhancement update	2011-12-06 01:02:36 UTC

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

Note You need to log in before you can comment on or make changes to this bug.