A security issue has been reported in util-linux, which can be exploited by malicious, local users to cause a DoS (Denial of Service). The security is caused due to the "mount" utility not properly handling the SIGXFSZ signal when e.g. adding new file system descriptions to "/etc/mtab", which can be exploited to e.g. corrupt the "/etc/mtab" file or leave a stale "/etc/mtab~" file by setting a low RLIMIT_FSIZE limit. Solution Restrict access to trusted users only. Provided and/or discovered by Dan Rosenberg Original Advisory http://www.openwall.com/lists/oss-security/2011/03/04/9 http://www.openwall.com/lists/oss-security/2011/03/15/6
ive added util-linux-2.19.1 to the tree which should have a fix for this
(In reply to comment #1) > ive added util-linux-2.19.1 to the tree which should have a fix for this Great, thank you. Arches, please test and mark stable: =sys-apps/util-linux-2.19.1 Target keywords : "alpha amd64 arm hppa ia64 m68k ppc ppc64 s390 sh sparc x86"
works here
amd64 done. Thanks Agostino
Stable for HPPA.
x86 stable. Thanks
arm stable
ppc/ppc64 stable
alpha/ia64/m68k/s390/sh/sparc stable
Thanks, everyone. GLSA request filed.
CVE-2011-1677 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2011-1677): mount in util-linux 2.19 and earlier does not remove the /etc/mtab~ lock file after a failed attempt to add a mount entry, which has unspecified impact and local attack vectors. CVE-2011-1676 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2011-1676): 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. CVE-2011-1675 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2011-1675): mount in util-linux 2.19 and earlier attempts to append to the /etc/mtab.tmp file without first checking whether resource limits would interfere, which allows local users to trigger corruption of the /etc/mtab file via a process with a small RLIMIT_FSIZE value, a related issue to CVE-2011-1089.
This issue was resolved and addressed in GLSA 201405-15 at http://security.gentoo.org/glsa/glsa-201405-15.xml by GLSA coordinator Sean Amoss (ackle).