[Acked] [SRU][lts-utopic] ovl: use O_LARGEFILE in ovl_copy_up()

Andy Whitcroft apw at canonical.com
Mon Dec 7 17:06:31 UTC 2015


On Sun, Dec 06, 2015 at 04:40:30PM +0000, Luis Henriques wrote:
> From: David Howells <dhowells at redhat.com>
> 
> 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 at redhat.com>
> Signed-off-by: David Howells <dhowells at redhat.com>
> Signed-off-by: Miklos Szeredi <miklos at szeredi.hu>
> Cc: <stable at vger.kernel.org> # v3.18+
> (cherry picked from commit 0480334fa60488d12ae101a02d7d9e1a3d03d7dd)
> BugLink: https://bugs.launchpad.net/bugs/1523000
> Signed-off-by: Luis Henriques <luis.henriques at canonical.com>
> ---
>  fs/overlayfs/copy_up.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/fs/overlayfs/copy_up.c b/fs/overlayfs/copy_up.c
> index ea1ec4933b14..092c6b79c14b 100644
> --- a/fs/overlayfs/copy_up.c
> +++ b/fs/overlayfs/copy_up.c
> @@ -80,11 +80,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;
> 

Yep, we should keep in mind that overlayfs is a little ahead of the game
in utopic.

Acked-by: Andy Whitcroft <apw at canonical.com>

-apw




More information about the kernel-team mailing list