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/15661] New: posix_fallocate fallback code buggy and dangerous


http://sourceware.org/bugzilla/show_bug.cgi?id=15661

            Bug ID: 15661
           Summary: posix_fallocate fallback code buggy and dangerous
           Product: glibc
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: libc
          Assignee: unassigned at sourceware dot org
          Reporter: bugdal at aerifal dot cx
                CC: drepper.fsp at gmail dot com

When the fallocate syscall returns EOPNOTSUPP, glibc tries to emulate it via
checking the file size and, if the file size needs to be extended, writing a
single zero byte at the location that should be the new last byte of the file,
via pwrite. This approach is broken for two reasons:

1. For files opened in O_APPEND mode, pwrite will simply write at the current
position, extending the file by 1 byte rather than the correct amount.

2. Checking the size then writing at a location past the end of the file
involves a race condition that could lead to data corruption. If the file is
extended by another thread or process after the size is checked but before
pwrite is called, pwrite may overwrite data rather than writing to a new
location past the end of the file.

Problem 1 could be fixed via a larger write of zeros, but I see no fix for
problem 2. As such, I believe the buggy fallback code in posix_fallocate should
simply be removed, and the function should return an error to the application
rather than trying to emulate it.

-- 
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]