Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Fri, 14 Apr 2023 14:37:00 +0200
From:   Christian Brauner <brauner@kernel.org>
To:     Luca Vizzarro <Luca.Vizzarro@arm.com>
Cc:     linux-kernel@vger.kernel.org,
        Kevin Brodsky <Kevin.Brodsky@arm.com>,
        Szabolcs Nagy <Szabolcs.Nagy@arm.com>,
        Theodore Ts'o <tytso@mit.edu>,
        David Laight <David.Laight@ACULAB.com>,
        Mark Rutland <Mark.Rutland@arm.com>,
        Alexander Viro <viro@zeniv.linux.org.uk>,
        Jeff Layton <jlayton@kernel.org>,
        Chuck Lever <chuck.lever@oracle.com>,
        linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH 0/5] Alter fcntl to handle int arguments correctly
Message-ID: <20230414-krumm-dekorativ-60ed7358b587@brauner>
References: <20230414100212.766118-1-Luca.Vizzarro@arm.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <20230414100212.766118-1-Luca.Vizzarro@arm.com>
Precedence: bulk

On Fri, Apr 14, 2023 at 11:02:07AM +0100, Luca Vizzarro wrote:
> According to the documentation of fcntl, some commands take an int as
> argument. In practice not all of them enforce this behaviour, as they
> instead accept a more permissive long and in most cases not even a
> range check is performed.
> 
> An issue could possibly arise from a combination of the handling of the
> varargs in user space and the ABI rules of the target, which may result
> in the top bits of an int argument being non-zero.
> 
> This issue was originally raised and detailed in the following thread:
>   https://lore.kernel.org/linux-api/Y1%2FDS6uoWP7OSkmd@arm.com/
> 
> This series modifies the interested commands so that they explicitly
> take an int argument. It also propagates this change down to helper and
> related functions as necessary.
> 
> This series is also available on my fork at:
>   https://git.morello-project.org/Sevenarth/linux/-/commits/fcntl-int-handling
> 
> Best regards,
> Luca Vizzarro
> 
> Luca Vizzarro (5):
>   fcntl: Cast commands with int args explicitly
>   fs: Pass argument to fcntl_setlease as int
>   pipe: Pass argument of pipe_fcntl as int
>   memfd: Pass argument of memfd_fcntl as int
>   dnotify: Pass argument of fcntl_dirnotify as int
> 
>  fs/cifs/cifsfs.c            |  2 +-
>  fs/fcntl.c                  | 29 +++++++++++++++--------------
>  fs/libfs.c                  |  2 +-
>  fs/locks.c                  | 20 ++++++++++----------
>  fs/nfs/nfs4_fs.h            |  2 +-
>  fs/nfs/nfs4file.c           |  2 +-
>  fs/nfs/nfs4proc.c           |  4 ++--
>  fs/notify/dnotify/dnotify.c |  4 ++--
>  fs/pipe.c                   |  6 +++---
>  include/linux/dnotify.h     |  4 ++--
>  include/linux/filelock.h    | 12 ++++++------
>  include/linux/fs.h          |  6 +++---
>  include/linux/memfd.h       |  4 ++--
>  include/linux/pipe_fs_i.h   |  4 ++--
>  mm/memfd.c                  |  6 +-----
>  15 files changed, 52 insertions(+), 55 deletions(-)
> 
> --
> 2.34.1
> 
> IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

Fyi, this blurb at the end breaks applying this series.

It means when someone pulls these patches down they get corrupted git
patches. You should fix your setup to not have this nonsense in your
mails. I tried to apply this for review to v6.2 up until v6.3-mainline
until I realized that the patches are corrupted by the blurb at the
end...