This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug libc/12625] New: mntent operations provide no indication of failure due to RLIMIT_FSIZE
- From: "dan.j.rosenberg at gmail dot com" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sources dot redhat dot com
- Date: Wed, 30 Mar 2011 19:19:22 +0000
- Subject: [Bug libc/12625] New: mntent operations provide no indication of failure due to RLIMIT_FSIZE
- Auto-submitted: auto-generated
http://sourceware.org/bugzilla/show_bug.cgi?id=12625
Summary: mntent operations provide no indication of failure due
to RLIMIT_FSIZE
Product: glibc
Version: unspecified
Status: NEW
Severity: normal
Priority: P2
Component: libc
AssignedTo: drepper.fsp@gmail.com
ReportedBy: dan.j.rosenberg@gmail.com
See thread on oss-security mailing list [1] for additional reference. This
issue has been assigned CVE-2011-1089.
Essentially every setuid mount helper, including util-linux mount, fails to
handle a low RLIMIT_FSIZE. Since addmntent() uses fprintf() without a
corresponding fflush(), it will return success even in the case when the actual
write will fail due to the resource limit. And then endmntent() always returns
1, so that's no help. As a result, these helpers can be used to write
corrupted entries into /etc/mtab.
Rather than forcing every setuid mount helper to explicitly alter resource
limits prior to calling addmntent(), etc., it would be better if addmntent()
attempted to flush and return failure based on the success of the fflush(), as
suggested by Tomas Hoger:
if (fprintf (stream, "%s %s %s %s %d %d\n", ...) < 0)
return 1;
return (fflush(stream) == 0 ? 0 : 1);
[1] http://www.openwall.com/lists/oss-security/2011/03/04/9
[2] http://www.openwall.com/lists/oss-security/2011/03/07/9
--
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.