Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Tue, 14 Nov 2017 12:17:57 -0500
From:   "J. Bruce Fields" <bfields@fieldses.org>
To:     Vitaly Lipatov <lav@etersoft.ru>
Cc:     wine-patches <wine-patches@winehq.org>,
        Jeff Layton <jlayton@poochiereds.net>,
        Alexander Viro <viro@zeniv.linux.org.uk>,
        linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3] fs/fcntl: restore checking against COMPAT_LOFF_T_MAX
 for F_GETLK64
Message-ID: <20171114171757.GF18192@fieldses.org>
References: <20171114134715.21649-1-lav@etersoft.ru>
 <20171114164818.6783-1-lav@etersoft.ru>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20171114164818.6783-1-lav@etersoft.ru>
User-Agent: Mutt/1.5.21 (2010-09-15)
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Tue, Nov 14, 2017 at 07:48:18PM +0300, Vitaly Lipatov wrote:
> for fcntl64 with F_GETLK64 we need use checking against COMPAT_LOFF_T_MAX.
> 
> Fixes: 94073ad77fff2 "fs/locks: don't mess with the address limit in compat_fcntl64"
> 
> Signed-off-by: Vitaly Lipatov <lav@etersoft.ru>
> ---
>  fs/fcntl.c | 14 +++++++-------
>  1 file changed, 7 insertions(+), 7 deletions(-)
> 
> diff --git a/fs/fcntl.c b/fs/fcntl.c
> index 30f47d0..e9443d9 100644
> --- a/fs/fcntl.c
> +++ b/fs/fcntl.c
> @@ -590,17 +590,17 @@ convert_fcntl_cmd(unsigned int cmd)
>   * GETLK was successful and we need to return the data, but it needs to fit in
>   * the compat structure.
>   * l_start shouldn't be too big, unless the original start + end is greater than

I assume that should be start + end.

> - * COMPAT_OFF_T_MAX, in which case the app was asking for trouble, so we return
> + * off_t_max, in which case the app was asking for trouble, so we return
>   * -EOVERFLOW in that case.

It took me a minute to understand.  OK, I get it, the application's not
supposed to issue a GETLK with offset+len too large, so of course it
shouldn't encounter a conflicting lock out there.

I don't think that's true, though, thanks to the special interpretation
of length 0 in the argument; it looks to me like we can find a conflict
with a lock that starts beyond COMPAT_OFF_T_MAX in that case.

I guess that's independent of your patch, though.

--b.

> l_len could be too big, in which case we just
>   * truncate it, and only allow the app to see that part of the conflicting lock
>   * that might make sense to it anyway
>   */
> -static int fixup_compat_flock(struct flock *flock)
> +static int fixup_compat_flock(struct flock *flock, loff_t off_t_max)
>  {
> -	if (flock->l_start > COMPAT_OFF_T_MAX)
> +	if (flock->l_start > off_t_max)
>  		return -EOVERFLOW;
> -	if (flock->l_len > COMPAT_OFF_T_MAX)
> -		flock->l_len = COMPAT_OFF_T_MAX;
> +	if (flock->l_len > off_t_max)
> +		flock->l_len = off_t_max;
>  	return 0;
>  }
>  
> @@ -631,7 +631,7 @@ COMPAT_SYSCALL_DEFINE3(fcntl64, unsigned int, fd, unsigned int, cmd,
>  		err = fcntl_getlk(f.file, convert_fcntl_cmd(cmd), &flock);
>  		if (err)
>  			break;
> -		err = fixup_compat_flock(&flock);
> +		err = fixup_compat_flock(&flock, COMPAT_OFF_T_MAX);
>  		if (err)
>  			return err;
>  		err = put_compat_flock(&flock, compat_ptr(arg));
> @@ -644,7 +644,7 @@ COMPAT_SYSCALL_DEFINE3(fcntl64, unsigned int, fd, unsigned int, cmd,
>  		err = fcntl_getlk(f.file, convert_fcntl_cmd(cmd), &flock);
>  		if (err)
>  			break;
> -		err = fixup_compat_flock(&flock);
> +		err = fixup_compat_flock(&flock, COMPAT_LOFF_T_MAX);
>  		if (err)
>  			return err;
>  		err = put_compat_flock64(&flock, compat_ptr(arg));
> -- 
> 2.10.4

From 1584061683748171366@xxx Tue Nov 14 17:02:23 +0000 2017
X-GM-THRID: 1584004086714411458
X-Gmail-Labels: Inbox,Category Forums,HistoricalUnread