Description of problem: _fcaps_load () uses uninitialized memory if fgetxattr () or getxattr () system call fails (and returns a negative value) because the signed result is compared to unsigned result of a sizeof () check, that comparison will always succeed if the system call returned a negative value. Version-Release number of selected component (if applicable): libcap-2.22-3.fc18 How reproducible: Almost always. Steps to Reproduce: 1. valgrind ls -lah --color Actual results: ==10387== Conditional jump or move depends on uninitialised value(s) ==10387== at 0x34F3A0299F: ??? (cap_file.c:36) ==10387== by 0x34F3A02B0C: cap_get_file (cap_file.c:224) ==10387== by 0x409762: gobble_file.constprop.46 (ls.c:2744) ==10387== by 0x404250: main (ls.c:2617) ==10387== Uninitialised value was created by a stack allocation Additional info: This will almost always not cause problems since _fcaps_load () checks the given result is valid by checking for some magic bytes and some other sanity checks. If those fail the result is discarded anyway. But if the random allocated memory would accidentally contain the magic bytes this could result in really hard to track down bugs.
Created attachment 698109 [details] libcap-2.22-signed-sizeof-compare.patch Fix syscall result check.
BTW. I wanted to check upstream, but the source URL given in the spec file points to an empty directory: http://www.kernel.org/pub/linux/libs/security/linux-privs/kernel-2.6/
Any update on this or a pointer where upstream is located so I can post my patch there? This is still an issue in f19 with libcap-2.22-5.fc19.x86_64
I think this is the upstream git repository for libcap: http://git.kernel.org/cgit/linux/kernel/git/morgan/libcap.git/ I haven't seen an announcement that libcap is deprecated or got officially replaced by libcap-ng, but there haven't been any commits for a long time.
(In reply to comment #4) > I think this is the upstream git repository for libcap: > > http://git.kernel.org/cgit/linux/kernel/git/morgan/libcap.git/ Thanks, I also send the patch to Andrew G. Morgan <morgan>. Could you apply it to the fedora package?
libcap-2.22-5.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/libcap-2.22-5.fc18
libcap-2.22-6.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/libcap-2.22-6.fc19
Package libcap-2.22-6.fc19: * should fix your issue, * was pushed to the Fedora 19 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing libcap-2.22-6.fc19' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-8170/libcap-2.22-6.fc19 then log in and leave karma (feedback).
libcap-2.22-6.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report.
libcap-2.22-5.fc18 has been pushed to the Fedora 18 stable repository. If problems still persist, please make note of it in this bug report.