diff options
| author | David Howells <dhowells@redhat.com> | 2015-09-18 11:45:12 +0100 |
|---|---|---|
| committer | Miklos Szeredi <miklos@szeredi.hu> | 2015-10-12 15:56:20 +0200 |
| commit | 0480334fa60488d12ae101a02d7d9e1a3d03d7dd (patch) | |
| tree | f9dfbb52a2ada460e3513bcf4e58ac488d8c9d3b | |
| parent | 64291f7db5bd8150a74ad2036f1037e6a0428df2 (diff) | |
| download | linux-stable-0480334fa60488d12ae101a02d7d9e1a3d03d7dd.tar.gz linux-stable-0480334fa60488d12ae101a02d7d9e1a3d03d7dd.tar.bz2 linux-stable-0480334fa60488d12ae101a02d7d9e1a3d03d7dd.zip | |
ovl: use O_LARGEFILE in ovl_copy_up()
Open the lower file with O_LARGEFILE in ovl_copy_up().
Pass O_LARGEFILE unconditionally in ovl_copy_up_data() as it's purely for
catching 32-bit userspace dealing with a file large enough that it'll be
mishandled if the application isn't aware that there might be an integer
overflow. Inside the kernel, there shouldn't be any problems.
Reported-by: Ulrich Obergfell <uobergfe@redhat.com>
Signed-off-by: David Howells <dhowells@redhat.com>
Signed-off-by: Miklos Szeredi <miklos@szeredi.hu>
Cc: <stable@vger.kernel.org> # v3.18+
| -rw-r--r-- | fs/overlayfs/copy_up.c | 4 |
1 files changed, 2 insertions, 2 deletions
diff --git a/fs/overlayfs/copy_up.c b/fs/overlayfs/copy_up.c index 84d693d37428..b1990ac8fa09 100644 --- a/fs/overlayfs/copy_up.c +++ b/fs/overlayfs/copy_up.c @@ -81,11 +81,11 @@ static int ovl_copy_up_data(struct path *old, struct path *new, loff_t len) if (len == 0) return 0; - old_file = ovl_path_open(old, O_RDONLY); + old_file = ovl_path_open(old, O_LARGEFILE | O_RDONLY); if (IS_ERR(old_file)) return PTR_ERR(old_file); - new_file = ovl_path_open(new, O_WRONLY); + new_file = ovl_path_open(new, O_LARGEFILE | O_WRONLY); if (IS_ERR(new_file)) { error = PTR_ERR(new_file); goto out_fput; |