On Fri, Jul 24, 2020 at 2:12 AM Dmitry V. Levin <l...@altlinux.org> wrote:
>
> According to Documentation/driver-api/ioctl.rst, in order to support
> 32-bit user space running on a 64-bit kernel, each subsystem or driver
> that implements an ioctl callback handler must also implement the
> corresponding compat_ioctl handler.  The compat_ptr_ioctl() helper can
> be used in place of a custom compat_ioctl file operation for drivers
> that only take arguments that are pointers to compatible data
> structures.
>
> In case of NS_* ioctls only NS_GET_OWNER_UID accepts an argument, and
> this argument is a pointer to uid_t type, which is universally defined
> to __kernel_uid32_t.

This is potentially dangerous to rely on, as there are two parts that
are mismatched:

- user space does not see the kernel's uid_t definition, but has its own,
  which may be either the 16-bit or the 32-bit type. 32-bit uid_t was
  introduced with linux-2.3.39 in back in 2000. glibc was already
  using 32-bit uid_t at the time in user space, but uclibc only changed
  in 2003, and others may have been even later.

- the ioctl command number is defined (incorrectly) as if there was no
  argument, so if there is any user space that happens to be built with
  a 16-bit uid_t, this does not get caught.

       Arnd

> Reported-by: Ákos Uzonyi <uzonyi.a...@gmail.com>
> Fixes: 6786741dbf99 ("nsfs: add ioctl to get an owning user namespace for ns 
> file descriptor")
> Cc: sta...@vger.kernel.org # v4.9+
> Signed-off-by: Dmitry V. Levin <l...@altlinux.org>
> ---
>  fs/nsfs.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/fs/nsfs.c b/fs/nsfs.c
> index 800c1d0eb0d0..a00236bffa2c 100644
> --- a/fs/nsfs.c
> +++ b/fs/nsfs.c
> @@ -21,6 +21,7 @@ static long ns_ioctl(struct file *filp, unsigned int ioctl,
>  static const struct file_operations ns_file_operations = {
>         .llseek         = no_llseek,
>         .unlocked_ioctl = ns_ioctl,
> +       .compat_ioctl   = compat_ptr_ioctl,
>  };
>
>  static char *ns_dname(struct dentry *dentry, char *buffer, int buflen)

Reply via email to