This is the mail archive of the glibc-bugs@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug libc/12625] New: mntent operations provide no indication of failure due to RLIMIT_FSIZE


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]