From: "H. Peter Anvin" <hpa@zytor.com>
To: "H. Peter Anvin" <hpa@zytor.com>
Cc: Linus Torvalds <torvalds@osdl.org>,
Ulrich Drepper <drepper@redhat.com>, Andi Kleen <ak@suse.de>,
"Viro, Al" <viro@ftp.linux.org.uk>,
linux-kernel <linux-kernel@vger.kernel.org>
Subject: [PATCH] Limit sendfile() to 2^31-PAGE_CACHE_SIZE bytes without error
Date: Tue, 03 Jan 2006 21:33:22 -0800 [thread overview]
Message-ID: <43BB5E22.2010306@zytor.com> (raw)
In-Reply-To: <43BB5646.2040504@zytor.com>
[-- Attachment #1: Type: text/plain, Size: 820 bytes --]
sendfile() has a limit of 2^31-1 bytes even on 64-bit platforms. Linus
wants to maintain it in order to avoid potential future security bugs
(always a good thing.)
This patch changes the behaviour from returning EINVAL when this limit
is exceeded to returning a short count. This means that a
properly-written userspace program will simply loop around and continue;
it will expose bugs in improperly-written userspace programs, which is
also a good thing. Additionally, the limit becomes an issue that is
completely contained within the kernel, and not encoded in the kernel
ABI, so it can be changed in the future.
(I set the limit to 2^31-PAGE_CACHE_SIZE so that a transfer that starts
at the beginning of the file will continue to be page-aligned.)
The
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
[-- Attachment #2: sendfile.patch --]
[-- Type: text/x-patch, Size: 658 bytes --]
diff --git a/fs/read_write.c b/fs/read_write.c
index a091ee4..3712886 100644
--- a/fs/read_write.c
+++ b/fs/read_write.c
@@ -9,6 +9,7 @@
#include <linux/fcntl.h>
#include <linux/file.h>
#include <linux/uio.h>
+#include <linux/pagemap.h>
#include <linux/smp_lock.h>
#include <linux/fsnotify.h>
#include <linux/security.h>
@@ -631,6 +632,9 @@ static ssize_t do_sendfile(int out_fd, i
ssize_t retval;
int fput_needed_in, fput_needed_out;
+ /* Avoid potential security holes. User space will get a short count and should loop. */
+ count = min(count, (size_t)0x80000000-PAGE_CACHE_SIZE);
+
/*
* Get input file, and verify that it is ok..
*/
next parent reply other threads:[~2006-01-04 5:34 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <43BB348F.3070108@zytor.com>
[not found] ` <200601040451.20411.ak@suse.de>
[not found] ` <Pine.LNX.4.64.0601032051300.3668@g5.osdl.org>
[not found] ` <43BB5646.2040504@zytor.com>
2006-01-04 5:33 ` H. Peter Anvin [this message]
2006-01-04 17:02 ` [PATCH] Limit sendfile() to 2^31-PAGE_CACHE_SIZE bytes without error Linus Torvalds
2006-01-04 17:16 ` Ulrich Drepper
2006-01-04 18:41 ` H. Peter Anvin
2006-01-04 18:40 ` Linus Torvalds
2006-01-04 18:58 ` H. Peter Anvin
2006-01-04 19:28 ` Linus Torvalds
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=43BB5E22.2010306@zytor.com \
--to=hpa@zytor.com \
--cc=ak@suse.de \
--cc=drepper@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@osdl.org \
--cc=viro@ftp.linux.org.uk \
/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