Red Hat Bugzilla – Bug 695921
CVE-2011-1676 util-linux: mount does not remove /etc/mtab.tmp after failed mount entry addition
Last modified: 2011-04-27 14:14:36 EDT
Common Vulnerabilities and Exposures assigned an identifier CVE-2011-1676 to the following vulnerability: Name: CVE-2011-1676 URL: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-1676 Assigned: 20110409 Reference: http://openwall.com/lists/oss-security/2011/03/04/11 Reference: http://openwall.com/lists/oss-security/2011/03/04/9 Reference: http://openwall.com/lists/oss-security/2011/03/04/10 Reference: http://openwall.com/lists/oss-security/2011/03/04/12 Reference: http://openwall.com/lists/oss-security/2011/03/05/3 Reference: http://openwall.com/lists/oss-security/2011/03/05/7 Reference: http://openwall.com/lists/oss-security/2011/03/07/9 Reference: http://openwall.com/lists/oss-security/2011/03/14/5 Reference: http://openwall.com/lists/oss-security/2011/03/14/7 Reference: http://openwall.com/lists/oss-security/2011/03/14/16 Reference: http://openwall.com/lists/oss-security/2011/03/15/6 Reference: http://openwall.com/lists/oss-security/2011/03/22/4 Reference: http://openwall.com/lists/oss-security/2011/03/22/6 Reference: http://openwall.com/lists/oss-security/2011/03/31/3 Reference: http://openwall.com/lists/oss-security/2011/03/31/4 Reference: http://openwall.com/lists/oss-security/2011/04/01/2 Reference: https://bugzilla.redhat.com/show_bug.cgi?id=688980 mount in util-linux 2.19 and earlier does not remove the /etc/mtab.tmp file after a failed attempt to add a mount entry, which allows local users to trigger corruption of the /etc/mtab file via multiple invocations.
Created util-linux-ng tracking bugs for this issue Affects: fedora-all [bug 695940]
I'd like to see reproducer for this bug. mount(8) blocks all signals when writing to mtab, the lockfile should be always removed. I'm able to reproduce this problem on umount(8) only: # ulimit -f 1 # umount /mnt/test # ls -la /etc/mtab* -rw-r--r-- 1 root root 2387 Apr 13 10:06 /etc/mtab -rw------- 1 root root 0 Apr 13 10:07 /etc/mtab~ -rw------- 1 root root 1024 Apr 13 10:07 /etc/mtab.tmp (mtab~ is lockfile, mtab.tmp is temporary file).
Karel, do you actually see any issue with leaving mtab.tmp file around? Unlike lock file (mtab~) existence, existence of this temporary file does not block further use of mount / umount and the file is overwritten as needed. I currently fail to see a way to trigger mtab corruption as mentioned in the CVE description. Is there anything I'm missing, or is this non-issue that should be disputed?
No, the file is unimportant and always overwritten during mtab update.
Thank you, closing as not-a-bug. Reporter also confirms there's no issue with mtab.tmp handling: http://thread.gmane.org/gmane.comp.security.oss.general/4374/focus=4983