Re: [PATCH] hid/uhid: fix a double-fetch bug when copying event from user

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Sep 18, 2017 at 10:21 PM, Meng Xu <mengxu.gatech@xxxxxxxxx> wrote:
> When in_compat_syscall(), a user could make type != UHID_CREATE when
> get_user(type, buffer) [first fetch] and later make event->type ==
> UHID_CREATE in copy_from_user(event, buffer, ...) [second fetch].
>
> By doing so, an attacker might circumvent the specific logic to handle
> the type == UHID_CREATE case and later cause undefined behaviors.
>
> This patch enforces that event->type is overriden to the type value
> copied in the first fetch and thus, mitigate this race condition attack.

I do not believe this mitigates anything, as copy_form_user() is not
an atomic operation and we can have 2nd thread "scrambling" the memory
while 1st does the ioctl.

We also should not expect that we always get consistent data from
userspace and the rest of the driver should be able to cope with
(reject) such data.

>
> Signed-off-by: Meng Xu <mengxu.gatech@xxxxxxxxx>
> ---
>  drivers/hid/uhid.c | 15 ++++++++++++---
>  1 file changed, 12 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/hid/uhid.c b/drivers/hid/uhid.c
> index 7f8ff39..4bbfd8a 100644
> --- a/drivers/hid/uhid.c
> +++ b/drivers/hid/uhid.c
> @@ -448,11 +448,20 @@ static int uhid_event_from_user(const char __user *buffer, size_t len,
>                         kfree(compat);
>                         return 0;
>                 }
> +
>                 /* All others can be copied directly */
> -       }
> +               if (copy_from_user(event, buffer, min(len, sizeof(*event))))
> +                       return -EFAULT;
>
> -       if (copy_from_user(event, buffer, min(len, sizeof(*event))))
> -               return -EFAULT;
> +               /*
> +                * Override type in case the user process rushes to change it
> +                * between two fetches
> +                * */
> +               event->type = type;

So if we started with UHID_INPUT, userspace replaced it with
UHID_FEATURE, we clobber the type UHID_INPUT leaving the rest of the
structure holding the new data and call it a day? That does not make
any sense to me.

> +       } else {
> +               if (copy_from_user(event, buffer, min(len, sizeof(*event))))
> +                       return -EFAULT;
> +       }
>
>         return 0;
>  }
> --
> 2.7.4
>

Thanks.

-- 
Dmitry
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Linux Media Devel]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Linux Wireless Networking]     [Linux Omap]

  Powered by Linux