All of lore.kernel.org
 help / color / mirror / Atom feed
From: Olga Kornievskaia <olga.kornievskaia@gmail.com>
To: trond.myklebust@hammerspace.com, anna.schumaker@netapp.com,
	viro@zeniv.linux.org.uk, smfrench@gmail.com, miklos@szeredi.hu
Cc: linux-nfs@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	linux-cifs@vger.kernel.org, linux-unionfs@vger.kernel.org
Subject: [PATCH v8 02/11] NFS: validity check for source offset in copy_file_range
Date: Thu,  1 Nov 2018 12:45:14 -0400	[thread overview]
Message-ID: <20181101164523.41812-3-olga.kornievskaia@gmail.com> (raw)
In-Reply-To: <20181101164523.41812-1-olga.kornievskaia@gmail.com>

From: Olga Kornievskaia <kolga@netapp.com>

copy_file_range() man page mandates that EINVAL is returned
if the specified range is beyond the end of the file but
currently does not enforce it.

NFS RFC 7832 states that "if the source offset or the source
offset plus count is greater than the size of the source file,
the operation MUST fail with NFS4ERR_INVAL."

>From the NFS community discussion from earlier on
https://www.spinics.net/lists/linux-nfs/msg62627.html
in was thought that offset plus count should instead be a
short read.

In this patch only proposing to enforce the offset check:
Input source offset can not be beyond the end of the file.

Future work in VFS might perform the arguments checks and
we can remove this check.

Signed-off-by: Olga Kornievskaia <kolga@netapp.com>
---
 fs/nfs/nfs4file.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/fs/nfs/nfs4file.c b/fs/nfs/nfs4file.c
index 5a73c90..7838bdf 100644
--- a/fs/nfs/nfs4file.c
+++ b/fs/nfs/nfs4file.c
@@ -135,6 +135,9 @@ static ssize_t nfs4_copy_file_range(struct file *file_in, loff_t pos_in,
 {
 	ssize_t ret;
 
+	if (pos_in >= i_size_read(file_inode(file_in)))
+		return -EINVAL;
+
 	if (file_inode(file_in)->i_sb != file_inode(file_out)->i_sb)
 		return -EXDEV;
 
-- 
1.8.3.1

WARNING: multiple messages have this Message-ID (diff)
From: Olga Kornievskaia <olga.kornievskaia@gmail.com>
To: trond.myklebust@hammerspace.com, anna.schumaker@netapp.com,
	viro@zeniv.linux.org.uk, smfrench@gmail.com, miklos@szeredi.hu
Cc: linux-nfs@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	linux-cifs@vger.kernel.org, linux-unionfs@vger.kernel.org
Subject: [PATCH v8 02/11] NFS: validity check for source offset in copy_file_range
Date: Thu,  1 Nov 2018 12:45:14 -0400	[thread overview]
Message-ID: <20181101164523.41812-3-olga.kornievskaia@gmail.com> (raw)
In-Reply-To: <20181101164523.41812-1-olga.kornievskaia@gmail.com>

From: Olga Kornievskaia <kolga@netapp.com>

copy_file_range() man page mandates that EINVAL is returned
if the specified range is beyond the end of the file but
currently does not enforce it.

NFS RFC 7832 states that "if the source offset or the source
offset plus count is greater than the size of the source file,
the operation MUST fail with NFS4ERR_INVAL."

From the NFS community discussion from earlier on
https://www.spinics.net/lists/linux-nfs/msg62627.html
in was thought that offset plus count should instead be a
short read.

In this patch only proposing to enforce the offset check:
Input source offset can not be beyond the end of the file.

Future work in VFS might perform the arguments checks and
we can remove this check.

Signed-off-by: Olga Kornievskaia <kolga@netapp.com>
---
 fs/nfs/nfs4file.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/fs/nfs/nfs4file.c b/fs/nfs/nfs4file.c
index 5a73c90..7838bdf 100644
--- a/fs/nfs/nfs4file.c
+++ b/fs/nfs/nfs4file.c
@@ -135,6 +135,9 @@ static ssize_t nfs4_copy_file_range(struct file *file_in, loff_t pos_in,
 {
 	ssize_t ret;
 
+	if (pos_in >= i_size_read(file_inode(file_in)))
+		return -EINVAL;
+
 	if (file_inode(file_in)->i_sb != file_inode(file_out)->i_sb)
 		return -EXDEV;
 
-- 
1.8.3.1


  parent reply	other threads:[~2018-11-01 16:45 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-11-01 16:45 [PATCH v8 00/11] client-side support for "inter" SSC copy Olga Kornievskaia
2018-11-01 16:45 ` [PATCH v8 01/11] VFS: move cross device copy_file_range() check into filesystems Olga Kornievskaia
2018-11-01 16:45 ` Olga Kornievskaia [this message]
2018-11-01 16:45   ` [PATCH v8 02/11] NFS: validity check for source offset in copy_file_range Olga Kornievskaia
2018-11-01 16:45 ` [PATCH v8 03/11] NFS NFSD: defining nl4_servers structure needed by both Olga Kornievskaia
2018-11-01 16:45 ` [PATCH v8 04/11] NFS: add COPY_NOTIFY operation Olga Kornievskaia
2018-11-01 16:45 ` [PATCH v8 05/11] NFS: add ca_source_server<> to COPY Olga Kornievskaia
2018-11-01 16:45 ` [PATCH v8 06/11] NFS: also send OFFLOAD_CANCEL to source server Olga Kornievskaia
2018-11-01 16:45 ` [PATCH v8 07/11] NFS: inter ssc open Olga Kornievskaia
2018-11-01 16:45 ` [PATCH v8 08/11] NFS: skip recovery of copy open on dest server Olga Kornievskaia
2018-11-01 16:45 ` [PATCH v8 09/11] NFS: for "inter" copy treat ESTALE as ENOTSUPP Olga Kornievskaia
2018-11-01 16:45 ` [PATCH v8 10/11] NFS: COPY handle ERR_OFFLOAD_DENIED Olga Kornievskaia
2018-11-01 16:45 ` [PATCH v8 11/11] NFS: replace cross device check in copy_file_range Olga Kornievskaia

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=20181101164523.41812-3-olga.kornievskaia@gmail.com \
    --to=olga.kornievskaia@gmail.com \
    --cc=anna.schumaker@netapp.com \
    --cc=linux-cifs@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-nfs@vger.kernel.org \
    --cc=linux-unionfs@vger.kernel.org \
    --cc=miklos@szeredi.hu \
    --cc=smfrench@gmail.com \
    --cc=trond.myklebust@hammerspace.com \
    --cc=viro@zeniv.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.