From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752614AbdBJKlX convert rfc822-to-8bit (ORCPT ); Fri, 10 Feb 2017 05:41:23 -0500 Received: from smtp-out4.electric.net ([192.162.216.190]:50827 "EHLO smtp-out4.electric.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752548AbdBJKlU (ORCPT ); Fri, 10 Feb 2017 05:41:20 -0500 From: David Laight To: "'Johannes Thumshirn'" , Scott Bauer , "linux-nvme@lists.infradead.org" CC: "arnd@arndb.de" , "axboe@fb.com" , "keith.busch@intel.com" , "jonathan.derrick@intel.com" , "hch@infradead.org" , "linux-kernel@vger.kernel.org" , "linux-block@vger.kernel.org" Subject: RE: [PATCH V3 2/2] Move stack parameters for sed_ioctl to prevent oversized stack with CONFIG_KASAN Thread-Topic: [PATCH V3 2/2] Move stack parameters for sed_ioctl to prevent oversized stack with CONFIG_KASAN Thread-Index: AQHSgvoUIzTRyNiITUSHxrFVtaAUiaFh3WIAgAAqX2A= Date: Fri, 10 Feb 2017 10:28:17 +0000 Message-ID: <063D6719AE5E284EB5DD2968C1650D6DB02833C4@AcuExch.aculab.com> References: <1486660801-5105-1-git-send-email-scott.bauer@intel.com> <1486660801-5105-3-git-send-email-scott.bauer@intel.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.202.99.200] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 X-Outbound-IP: 213.249.233.130 X-Env-From: David.Laight@ACULAB.COM X-Proto: esmtps X-Revdns: X-HELO: AcuExch.aculab.com X-TLS: TLSv1:AES128-SHA:128 X-Authenticated_ID: X-PolicySMART: 3396946, 3397078 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Johannes Thumshirn > Sent: 10 February 2017 07:46 > On 02/09/2017 06:20 PM, Scott Bauer wrote: > > When CONFIG_KASAN is enabled, compilation fails: Does CONFIG_KASAN allocate guard stack space around everything that is passed by address? That sounds completely brain-dead. There are a lot of functions that have an 'int *' argument to return a single value - and are never going to do anything else. ... > > Moved all the ioctl structures off the stack and dynamically activate > > using _IOC_SIZE() ... > > > - if (copy_from_user(&session, arg, sizeof(session))) > > - return -EFAULT; > > - return opal_erase_locking_range(dev, &session); > > + ioctl_ptr = kzalloc(cmd_size, GFP_KERNEL); > > + if (!ioctl_ptr) > > + return -ENOMEM; > > + if (copy_from_user(ioctl_ptr, arg, cmd_size)) { > > + ret = -EFAULT; > > + goto out; > > } > > Can't we use memdup_user() instead of kzalloc() + copy_from_user()? You either want the copy_from_user() or the memzero() not both. ISTM there could be two 'library' functions, maybe: void *get_ioctl_buf(unsigned int cmd, long arg) to malloc the buffer, memzero/copy_from_user, returns -EFAULT if copy fails. int put_ioctl_buf(int rval, unsigned int cmd, const void *buf) does copy_to_user() if rval >= 0 and IOR_READ, then frees buf. return value is rval unless the copyout fails. David