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.
next 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: linkBe 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).