linux-kernel - Re: [PATCH] staging: android: vsoc: fix copy_from

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20190415063244.GM6095@kadam>
Date:   Mon, 15 Apr 2019 09:32:44 +0300
From:   Dan Carpenter <dan.carpenter@...cle.com>
To:     Vincent Stehlé <vincent.stehle@...oste.net>
Cc:     devel@...verdev.osuosl.org, linux-kernel@...r.kernel.org,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Subject: Re: [PATCH] staging: android: vsoc: fix copy_from_user overrun

On Sun, Apr 14, 2019 at 05:37:26PM +0200, Vincent Stehlé wrote:
> The `np->permission' structure is smaller than the `np' structure but
> sizeof(*np) worth of data is copied in there. Fix the size passed to
> copy_from_user() to avoid overrun.
> 
> Fixes: 3d2ec9dcd5539d42 ("staging: Android: Add 'vsoc' driver for cuttlefish.")
> Signed-off-by: Vincent Stehlé <vincent.stehle@...oste.net>
> Cc: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
> ---
>  drivers/staging/android/vsoc.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/staging/android/vsoc.c b/drivers/staging/android/vsoc.c
> index 8a75bd27c4133..00a1ec7b91549 100644
> --- a/drivers/staging/android/vsoc.c
> +++ b/drivers/staging/android/vsoc.c
> @@ -259,7 +259,8 @@ do_create_fd_scoped_permission(struct vsoc_device_region *region_p,
>  	atomic_t *owner_ptr = NULL;
>  	struct vsoc_device_region *managed_region_p;
>  
> -	if (copy_from_user(&np->permission, &arg->perm, sizeof(*np)) ||
> +	if (copy_from_user(&np->permission,
> +			   &arg->perm, sizeof(np->permission)) ||

The original code was probably correct...  This is a common thing where
people use "&p->first_struct_member" to represent the whole struct.
It seems like kind of a horrible thing to do and I can't explain why
people do it, but they do...

regards,
dan carpenter