Hide Forgot
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.
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'
uid_t and gid_t are unsigned types -- unfortunately, ipcs(1) uses %d for the types...
Fixed by upstream commit 344f73442d3a45db5927c049eef1ed8cf5d13934.
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