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@xxxxxxx/ > > 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...
