Common Vulnerabilities and Exposures assigned an identifier CVE-2011-1676 to
the following vulnerability:
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
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: