public inbox for glibc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "bugdal at aerifal dot cx" <sourceware-bugzilla@sourceware.org>
To: glibc-bugs@sourceware.org
Subject: [Bug libc/15661] New: posix_fallocate fallback code buggy and dangerous
Date: Fri, 21 Jun 2013 00:10:00 -0000	[thread overview]
Message-ID: <bug-15661-131@http.sourceware.org/bugzilla/> (raw)

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.


             reply	other threads:[~2013-06-21  0:10 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-06-21  0:10 bugdal at aerifal dot cx [this message]
2013-06-21  0:59 ` [Bug libc/15661] " bugdal at aerifal dot cx
2013-06-24 16:43 ` zlynx at acm dot org
2014-06-13 15:02 ` fweimer at redhat dot com
2014-06-14  3:49 ` bugdal at aerifal dot cx
2015-04-24  8:00 ` Jean-Baptiste.Leonesio@esi-group.com
2015-04-24  8:01 ` Jean-Baptiste.Leonesio@esi-group.com
2015-04-24 11:42 ` fweimer at redhat dot com
2015-04-24 11:57 ` fweimer at redhat dot com
2015-06-03  3:49 ` carlos at redhat dot com
2015-06-03  4:23 ` bugdal at aerifal dot cx
2015-06-03  4:26 ` carlos at redhat dot com
2015-06-05  9:20 ` fweimer at redhat dot com
2015-06-05 13:16 ` fweimer at redhat dot com
2015-06-05 16:52 ` zlynx at acm dot org
2015-06-05 18:02 ` carlos at redhat dot com

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bug-15661-131@http.sourceware.org/bugzilla/ \
    --to=sourceware-bugzilla@sourceware.org \
    --cc=glibc-bugs@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).