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%[email protected]/
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.
The interface for fcntl expects the argument passed for the command
F_ADD_SEALS to be of type int. The current code wrongly treats it as
a long. In order to avoid access to undefined bits, we should explicitly
cast the argument to int.
This commit changes the signature of all the related and helper
functions so that they treat the argument as int instead of long.
Cc: Kevin Brodsky <[email protected]>
Cc: Szabolcs Nagy <[email protected]>
Cc: "Theodore Ts'o" <[email protected]>
Cc: David Laight <[email protected]>
Cc: Mark Rutland <[email protected]>
Cc: Alexander Viro <[email protected]>
Cc: Christian Brauner <[email protected]>
Cc: Jeff Layton <[email protected]>
Cc: Chuck Lever <[email protected]>
Cc: [email protected]
Cc: Andrew Morton <[email protected]>
Cc: [email protected]
Signed-off-by: Luca Vizzarro <[email protected]>
---
include/linux/memfd.h | 4 ++--
mm/memfd.c | 6 +-----
2 files changed, 3 insertions(+), 7 deletions(-)
diff --git a/include/linux/memfd.h b/include/linux/memfd.h
index 4f1600413f91..e7abf6fa4c52 100644
--- a/include/linux/memfd.h
+++ b/include/linux/memfd.h
@@ -5,9 +5,9 @@
#include <linux/file.h>
#ifdef CONFIG_MEMFD_CREATE
-extern long memfd_fcntl(struct file *file, unsigned int cmd, unsigned long arg);
+extern long memfd_fcntl(struct file *file, unsigned int cmd, unsigned int arg);
#else
-static inline long memfd_fcntl(struct file *f, unsigned int c, unsigned long a)
+static inline long memfd_fcntl(struct file *f, unsigned int c, unsigned int a)
{
return -EINVAL;
}
diff --git a/mm/memfd.c b/mm/memfd.c
index a0a7a37e8177..69b90c31d38c 100644
--- a/mm/memfd.c
+++ b/mm/memfd.c
@@ -243,16 +243,12 @@ static int memfd_get_seals(struct file *file)
return seals ? *seals : -EINVAL;
}
-long memfd_fcntl(struct file *file, unsigned int cmd, unsigned long arg)
+long memfd_fcntl(struct file *file, unsigned int cmd, unsigned int arg)
{
long error;
switch (cmd) {
case F_ADD_SEALS:
- /* disallow upper 32bit */
- if (arg > UINT_MAX)
- return -EINVAL;
-
error = memfd_add_seals(file, arg);
break;
case F_GET_SEALS:
--
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.
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%[email protected]/
>
> 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...
On 14/04/2023 13:37, Christian Brauner wrote
> 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...
Apologies! There was an error in my end with the selection of the SMTP
server. That was definitely not meant to be there! Will make sure to
repost correctly.