From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-4.0 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8F1C4C433DF for ; Thu, 30 Jul 2020 11:48:49 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 74CAD20838 for ; Thu, 30 Jul 2020 11:48:49 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728021AbgG3Lss (ORCPT ); Thu, 30 Jul 2020 07:48:48 -0400 Received: from mga18.intel.com ([134.134.136.126]:28320 "EHLO mga18.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726267AbgG3Lsr (ORCPT ); Thu, 30 Jul 2020 07:48:47 -0400 IronPort-SDR: 43OE7a9WJ395AqDiD2EuId75l8yCfaEudjVKoAVY4rwenWJ024TxGavR/pjIhzUZunw9TD13Jz D7l+S4cpxZTw== X-IronPort-AV: E=McAfee;i="6000,8403,9697"; a="139121723" X-IronPort-AV: E=Sophos;i="5.75,414,1589266800"; d="scan'208";a="139121723" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga005.fm.intel.com ([10.253.24.32]) by orsmga106.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 30 Jul 2020 04:48:47 -0700 IronPort-SDR: wmlhB2ZzttBFINXRufelrxv8L53CImhLZ6YLEBjkVR5V0gkzH1JXuIS1XD0H6dLKepNgiLNPuq Qw0S9w3OkVZQ== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.75,414,1589266800"; d="scan'208";a="491097611" Received: from smile.fi.intel.com (HELO smile) ([10.237.68.40]) by fmsmga005.fm.intel.com with ESMTP; 30 Jul 2020 04:48:43 -0700 Received: from andy by smile with local (Exim 4.94) (envelope-from ) id 1k173C-004ugB-9a; Thu, 30 Jul 2020 14:48:42 +0300 Date: Thu, 30 Jul 2020 14:48:42 +0300 From: Andy Shevchenko To: Arnd Bergmann Cc: Bartosz Golaszewski , Dan Carpenter , Linus Walleij , Peilin Ye , Mauro Carvalho Chehab , Greg Kroah-Hartman , syzkaller-bugs , Hans Verkuil , Sakari Ailus , Laurent Pinchart , Vandana BN , Ezequiel Garcia , Niklas =?iso-8859-1?Q?S=F6derlund?= , linux-kernel-mentees@lists.linuxfoundation.org, Linux Media Mailing List , "linux-kernel@vger.kernel.org" Subject: Re: [Linux-kernel-mentees] [PATCH v3] media/v4l2-core: Fix kernel-infoleak in video_put_user() Message-ID: <20200730114842.GH3703480@smile.fi.intel.com> References: <20200726222703.102701-1-yepeilin.cs@gmail.com> <20200727131608.GD1913@kadam> <20200728130632.GI1913@kadam> <20200730083833.GD3703480@smile.fi.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Jul 30, 2020 at 11:18:04AM +0200, Arnd Bergmann wrote: > On Thu, Jul 30, 2020 at 10:38 AM Andy Shevchenko > wrote: > > On Thu, Jul 30, 2020 at 10:15:24AM +0200, Arnd Bergmann wrote: > > > On Thu, Jul 30, 2020 at 10:07 AM Bartosz Golaszewski wrote: ... > > > I would argue that it needs to be fixed anyway, unless you also want > > > to remove the v1 interface for native mode. If this works on 32-bit > > > kernels, on 64-bit kernels with 64-bit user space and on compat > > > 32-bit user space on 64-bit non-x86 architectures, I see no reason > > > to leave it broken specifically on x86 compat user space. There are > > > still reasons to use 32-bit x86 user space for low-memory machines > > > even though native i386 kernels are getting increasingly silly. > > > > It was possible to "fix" (mitigate to some extent) before libgpiod got support > > for several events in a request. Now it seems to be impossible to fix. AFAIU we > > must discard any request to more than one event in it. > > Any reason why the workaround I suggested above would not work? That is the question to somebody who has better understanding. If it works, I vote up to get it fixed with little effort. I would be glad to test patches! > The in_ia32_syscall() check should be completely reliable in telling whether > we are called from read() by an ia32 task or not, and we use the same > logic for input_event, which has a similar problem (on all compat architectures, > not just x86). By the way any reason why we have to have in_ia32_syscall() instead of in_compat_syscall()? > > However I'm not an expert in compat IOCTL code (you are :-) and perhaps you may > > provide ideas better than mine. > > What makes this interface tricky is that this is actually a read() call, not > ioctl() which is usually easier because it encodes the data length in the > command code. As far as I could tell from skimming the interface, the > ioctls are actually fine here. Right. -- With Best Regards, Andy Shevchenko From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-4.0 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 5FDD4C433DF for ; Thu, 30 Jul 2020 11:48:52 +0000 (UTC) Received: from fraxinus.osuosl.org (smtp4.osuosl.org [140.211.166.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 3C6AF21D95 for ; Thu, 30 Jul 2020 11:48:52 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 3C6AF21D95 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linux.intel.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=linux-kernel-mentees-bounces@lists.linuxfoundation.org Received: from localhost (localhost [127.0.0.1]) by fraxinus.osuosl.org (Postfix) with ESMTP id 0CC5586A7F; Thu, 30 Jul 2020 11:48:52 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from fraxinus.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VAF7Ban-R2yW; Thu, 30 Jul 2020 11:48:51 +0000 (UTC) Received: from lists.linuxfoundation.org (lf-lists.osuosl.org [140.211.9.56]) by fraxinus.osuosl.org (Postfix) with ESMTP id 68766862D4; Thu, 30 Jul 2020 11:48:51 +0000 (UTC) Received: from lf-lists.osuosl.org (localhost [127.0.0.1]) by lists.linuxfoundation.org (Postfix) with ESMTP id 4C30EC004F; Thu, 30 Jul 2020 11:48:51 +0000 (UTC) Received: from hemlock.osuosl.org (smtp2.osuosl.org [140.211.166.133]) by lists.linuxfoundation.org (Postfix) with ESMTP id 24664C004D for ; Thu, 30 Jul 2020 11:48:50 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by hemlock.osuosl.org (Postfix) with ESMTP id 0CBBE87ADB for ; Thu, 30 Jul 2020 11:48:50 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from hemlock.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HIR5t-dQmFKL for ; Thu, 30 Jul 2020 11:48:47 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by hemlock.osuosl.org (Postfix) with ESMTPS id 84EE68664E for ; Thu, 30 Jul 2020 11:48:47 +0000 (UTC) IronPort-SDR: MlavBrHr7Gc+d4sIkiIHvenbVivW6NX8uipDYv3XNd0OhKss2IF1qeP8wJdNogpBrBCKjJcx/c EczEnbFaLqDw== X-IronPort-AV: E=McAfee;i="6000,8403,9697"; a="149415531" X-IronPort-AV: E=Sophos;i="5.75,414,1589266800"; d="scan'208";a="149415531" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga005.fm.intel.com ([10.253.24.32]) by fmsmga102.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 30 Jul 2020 04:48:47 -0700 IronPort-SDR: wmlhB2ZzttBFINXRufelrxv8L53CImhLZ6YLEBjkVR5V0gkzH1JXuIS1XD0H6dLKepNgiLNPuq Qw0S9w3OkVZQ== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.75,414,1589266800"; d="scan'208";a="491097611" Received: from smile.fi.intel.com (HELO smile) ([10.237.68.40]) by fmsmga005.fm.intel.com with ESMTP; 30 Jul 2020 04:48:43 -0700 Received: from andy by smile with local (Exim 4.94) (envelope-from ) id 1k173C-004ugB-9a; Thu, 30 Jul 2020 14:48:42 +0300 Date: Thu, 30 Jul 2020 14:48:42 +0300 From: Andy Shevchenko To: Arnd Bergmann Message-ID: <20200730114842.GH3703480@smile.fi.intel.com> References: <20200726222703.102701-1-yepeilin.cs@gmail.com> <20200727131608.GD1913@kadam> <20200728130632.GI1913@kadam> <20200730083833.GD3703480@smile.fi.intel.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo Cc: Niklas =?iso-8859-1?Q?S=F6derlund?= , "linux-kernel@vger.kernel.org" , Bartosz Golaszewski , syzkaller-bugs , Linux Media Mailing List , Peilin Ye , Laurent Pinchart , Sakari Ailus , Vandana BN , Hans Verkuil , Mauro Carvalho Chehab , Ezequiel Garcia , Linus Walleij , Dan Carpenter , linux-kernel-mentees@lists.linuxfoundation.org Subject: Re: [Linux-kernel-mentees] [PATCH v3] media/v4l2-core: Fix kernel-infoleak in video_put_user() X-BeenThere: linux-kernel-mentees@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: linux-kernel-mentees-bounces@lists.linuxfoundation.org Sender: "Linux-kernel-mentees" On Thu, Jul 30, 2020 at 11:18:04AM +0200, Arnd Bergmann wrote: > On Thu, Jul 30, 2020 at 10:38 AM Andy Shevchenko > wrote: > > On Thu, Jul 30, 2020 at 10:15:24AM +0200, Arnd Bergmann wrote: > > > On Thu, Jul 30, 2020 at 10:07 AM Bartosz Golaszewski wrote: ... > > > I would argue that it needs to be fixed anyway, unless you also want > > > to remove the v1 interface for native mode. If this works on 32-bit > > > kernels, on 64-bit kernels with 64-bit user space and on compat > > > 32-bit user space on 64-bit non-x86 architectures, I see no reason > > > to leave it broken specifically on x86 compat user space. There are > > > still reasons to use 32-bit x86 user space for low-memory machines > > > even though native i386 kernels are getting increasingly silly. > > > > It was possible to "fix" (mitigate to some extent) before libgpiod got support > > for several events in a request. Now it seems to be impossible to fix. AFAIU we > > must discard any request to more than one event in it. > > Any reason why the workaround I suggested above would not work? That is the question to somebody who has better understanding. If it works, I vote up to get it fixed with little effort. I would be glad to test patches! > The in_ia32_syscall() check should be completely reliable in telling whether > we are called from read() by an ia32 task or not, and we use the same > logic for input_event, which has a similar problem (on all compat architectures, > not just x86). By the way any reason why we have to have in_ia32_syscall() instead of in_compat_syscall()? > > However I'm not an expert in compat IOCTL code (you are :-) and perhaps you may > > provide ideas better than mine. > > What makes this interface tricky is that this is actually a read() call, not > ioctl() which is usually easier because it encodes the data length in the > command code. As far as I could tell from skimming the interface, the > ioctls are actually fine here. Right. -- With Best Regards, Andy Shevchenko _______________________________________________ Linux-kernel-mentees mailing list Linux-kernel-mentees@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/linux-kernel-mentees