From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754434AbbLJXry (ORCPT ); Thu, 10 Dec 2015 18:47:54 -0500 Received: from wimdewith.com ([188.226.197.86]:46289 "EHLO wimdewith.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751094AbbLJXrw (ORCPT ); Thu, 10 Dec 2015 18:47:52 -0500 Date: Fri, 11 Dec 2015 00:47:38 +0100 From: Wim de With To: One Thousand Gnomes Cc: gregkh@linuxfoundation.org, devel@driverdev.osuosl.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v2] staging: gdm72xx: add userspace data struct Message-ID: <20151210234738.GA28422@boole.wimdewith.com> References: <20151210113421.GE5284@mwanda> <1449747648-24347-1-git-send-email-nauxuron@wimdewith.com> <20151210144445.669ea27a@lxorguk.ukuu.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20151210144445.669ea27a@lxorguk.ukuu.org.uk> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Dec 10, 2015 at 02:44:45PM +0000, One Thousand Gnomes wrote: > (except that you mean sizeof(struct fsm_s) and it doesn't compile at the > moment! Oops, sloppy mistake. > data_s can just be modified to be __user. All uses of it follow that > rule. What do you mean? The data still needs to be copied from user space to kernel space, if I'm not mistaken. And not all uses follow that rule, since in both gdm_wimax_ioctl_get_data() and gdm_wimax_ioctl_set_data() it is used as both the source and destination in the copy_from_user() and copy_to_user() call. > All I think you need in this case is > > struct fsm_s fsm_buf; > > if (copy_from_user(&fsm_buf, req->data.buf,sizeof(buf)) > return -EFAULT > gdm_update_fsm(&fsm_buf); Do you mean sizeof(fsm_s)? I realize this would have been far simpler than my overkill solution. > If you are touching the structs it might be wise to fix the other > problems with them notably the use of int. sizes when used are unsigned - > and signed sizes are asking for errors. In fact if you look at the > existing uses of the size checks they look deeply suspicious the moment > anything malicious passes in negative numbers. I would love to do that, but it is a bit outside the scope of this patch, so I would rather safe this for another patch.