This is an automatically created tracking bug! It was created to ensure that one or more security vulnerabilities are fixed in affected Fedora versions. For comments that are specific to the vulnerability please use bugs filed against "Security Response" product referenced in the "Blocks" field. For more information see: http://fedoraproject.org/wiki/Security/TrackingBugs When creating a Bodhi update request, please include the bug IDs of the respective parent bugs filed against the "Security Response" product. Please mention CVE ids in the RPM changelog when available. Bodhi update submission link: https://admin.fedoraproject.org/updates/new/?type_=security&bugs=695916 Please note: this issue affects multiple supported versions of Fedora. Only one tracking bug has been filed; please only close it when all affected versions are fixed. [bug automatically created by: add-tracking-bugs]
Adding parent bug CVE-2011-1676 New bodhi update url: https://admin.fedoraproject.org/updates/new/?type_=security&bugs=695916,695921
Adding parent bug CVE-2011-1677 New bodhi update url: https://admin.fedoraproject.org/updates/new/?type_=security&bugs=695916,695921,695924
Note that all these issues are fixed in upstream release 2.19.1-rc1. This fixed version of the package is already available in rawhide. Fedora-15 is going to be updated after stable 2.19.1 release.
(In reply to comment #3) > Note that all these issues are fixed in upstream release 2.19.1-rc1. This fixed > version of the package is already available in rawhide. Fedora-15 is going to > be updated after stable 2.19.1 release. Can you add links to upstream patches fixing these issues to relevant parent bug, if you have them handy? TY!
It's more patches, the most important are probably: mount: use fflush() and temporary file for mtab updates (CVE-2011-1089) http://git.kernel.org/?p=utils/util-linux/util-linux.git;a=commit;h=4b39b6aefd5dd8ac68a92adc650dc13d5d54d704 umount: block signals when umounting and updating mtab (CVE-2011-1676, CVE-2011-1677) http://git.kernel.org/?p=utils/util-linux/util-linux.git;a=commit;h=11b51a46bfd3c340df251b2d20fe9d04d077a88e libmount: more robust mtab and utab update (CVE-2011-1676, CVE-2011-1677) http://git.kernel.org/?p=utils/util-linux/util-linux.git;a=commit;h=84ed14022e7d3d121bbcab60ebad11ed38d691b0 libmount: block signals when update utab http://git.kernel.org/?p=utils/util-linux/util-linux.git;a=commit;h=28594c9d4fc8a4108408c5749b62933b967ba23b Note that these patches are backports to the 2.19 release, the original patches in the master branch could be a little different, but the basic logic should be the same: - always write to temporary file - always care about fprintf() return values - always call fflush() for the temporary file - blocks signals when updating mtab file (the signals are unblocked after update, lock and temporary file clean up) The fixed mount/umount does not modify RLIMIT_FSIZE setting as was suggested in the discussion at security.oss mailing list. I have doubts that this is a good idea. The user is able to mount/umount only user-mounts ('user' option in fstab), so it's his problem if the entry for the filesystem will not be in the mtab file (he will not able to successfully umount the filesystem). The other users will not be affected and the root user is able to umount filesystems independently on the mtab file. So it seems that play any crazy games with setrlimit() will not increase security.
All these issues should be already fixed in F16. Closing.