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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 94AE4C4332F for ; Thu, 20 Oct 2022 16:07:43 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 000408E0002; Thu, 20 Oct 2022 12:07:43 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id EF1408E0001; Thu, 20 Oct 2022 12:07:42 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id DE08D8E0002; Thu, 20 Oct 2022 12:07:42 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id CF8BA8E0001 for ; Thu, 20 Oct 2022 12:07:42 -0400 (EDT) Received: from smtpin28.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 7CD6EC11E8 for ; Thu, 20 Oct 2022 16:07:42 +0000 (UTC) X-FDA: 80041808364.28.BE2F68E Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by imf11.hostedemail.com (Postfix) with ESMTP id 6831240042 for ; Thu, 20 Oct 2022 16:07:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1666282061; x=1697818061; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=A8H1XSPG3teHKYUp6wZ4Z92OLMc+S/wpfm0q02AUrZ8=; b=JgXqYL2MXR7kaIdhEDVuAjwNSitQsBXS3dMunCk244UyTlwqKJxbX9XR fUAtnZqqlp+DduPq1MsOp20j2JF7YGfMFg04QC7uRB408h6IJKlwUm1mh VQAC/E5FbvpK3VGfBBFsWnK1C/vvJkv8P43jZpTG9bMuLL4XJzuQU+QWP wLOCojIGjLbXq3MtzbKPxr87TjJjFH+WolbiLNFt8myZXErt1+AKMzuYx A5ODirKVAODbzZ5GKZGOJNRB59TxBPZ/Lb5IdXCzJdfI7QOKKyRyRMRLD kj615eARhWK/YFEGRfzMgvkmbNcV20oEqSmRYtGtBZZMSTqhbM9sH3yp5 g==; X-IronPort-AV: E=McAfee;i="6500,9779,10506"; a="308435875" X-IronPort-AV: E=Sophos;i="5.95,199,1661842800"; d="scan'208";a="308435875" Received: from fmsmga004.fm.intel.com ([10.253.24.48]) by orsmga103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 20 Oct 2022 09:03:28 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6500,9779,10506"; a="698748301" X-IronPort-AV: E=Sophos;i="5.95,199,1661842800"; d="scan'208";a="698748301" Received: from smile.fi.intel.com ([10.237.72.54]) by fmsmga004.fm.intel.com with ESMTP; 20 Oct 2022 09:03:25 -0700 Received: from andy by smile.fi.intel.com with local (Exim 4.96) (envelope-from ) id 1olY0x-00AcyW-2M; Thu, 20 Oct 2022 19:03:23 +0300 Date: Thu, 20 Oct 2022 19:03:23 +0300 From: Andy Shevchenko To: Konrad Rzeszutek Wilk Cc: Jane Chu , pmladek@suse.com, rostedt@goodmis.org, senozhatsky@chromium.org, linux@rasmusvillemoes.dk, linux-mm@kvack.org, linux-kernel@vger.kernel.org, wangkefeng.wang@huawei.com, haakon.bugge@oracle.com, john.haxby@oracle.com Subject: Re: [PATCH v3 1/1] vsprintf: protect kernel from panic due to non-canonical pointer dereference Message-ID: References: <20221019194159.2923873-1-jane.chu@oracle.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 ARC-Authentication-Results: i=1; imf11.hostedemail.com; dkim=none ("invalid DKIM record") header.d=intel.com header.s=Intel header.b=JgXqYL2M; dmarc=fail reason="No valid SPF" header.from=intel.com (policy=none); spf=none (imf11.hostedemail.com: domain of andriy.shevchenko@linux.intel.com has no SPF policy when checking 134.134.136.65) smtp.mailfrom=andriy.shevchenko@linux.intel.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1666282062; a=rsa-sha256; cv=none; b=HTr1VwiRI+l5UPxckqmfPnCGddmJ8Kqwm8x9ax+7zsfvrpcACkj2LHAOrerTAmExv9fC0E K6HOkwb/VGKT3BgMovk1BV+/IKXSKeEXUETjz8n/ojxhVFQ9uFuX0k47NzjbDu6eMeD+BF XWGohBuk1US3kqN6qVjEA0SMVe6tzwc= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1666282062; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=0voUrQ65Vlury01hmf3n7f9GkN912MuekTUzRCQMSyQ=; b=0aDe8xK0hKw/fniXiAKdS0KCzxJmEMkTBGe5Y/b0Ba/7OXA9MnLSwjl0LAo/kf9u9rfB+p P8S8y1oYzlDh7xs+3+wInBeCvs2fuY88m1Ge/cUv5cdlhQi2XpL+ZWxW9XFWDbOHn4SzTp mbmgAg+JevM/3SW8Q0uKWiwh44c3S5U= Authentication-Results: imf11.hostedemail.com; dkim=none ("invalid DKIM record") header.d=intel.com header.s=Intel header.b=JgXqYL2M; dmarc=fail reason="No valid SPF" header.from=intel.com (policy=none); spf=none (imf11.hostedemail.com: domain of andriy.shevchenko@linux.intel.com has no SPF policy when checking 134.134.136.65) smtp.mailfrom=andriy.shevchenko@linux.intel.com X-Rspam-User: X-Rspamd-Server: rspam06 X-Stat-Signature: 6i66mbpyefoxaa78akyrtye5habx1wkm X-Rspamd-Queue-Id: 6831240042 X-HE-Tag: 1666282061-166853 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Thu, Oct 20, 2022 at 10:52:03AM -0400, Konrad Rzeszutek Wilk wrote: > On Wed, Oct 19, 2022 at 11:33:47PM +0300, Andy Shevchenko wrote: > > On Wed, Oct 19, 2022 at 01:41:59PM -0600, Jane Chu wrote: > > > Having stepped on a local kernel bug where reading sysfs has led to > > > out-of-bound pointer dereference by vsprintf() which led to GPF panic. > > > And the reason for GPF is that the OOB pointer was turned to a > > > non-canonical address such as 0x7665645f63616465. > > > > > > vsprintf() already has this line of defense > > > if ((unsigned long)ptr < PAGE_SIZE || IS_ERR_VALUE(ptr)) > > > return "(efault)"; > > > Since a non-canonical pointer can be detected by kern_addr_valid() > > > on architectures that present VM holes as well as meaningful > > > implementation of kern_addr_valid() that detects the non-canonical > > > addresses, this patch adds a check on non-canonical string pointer by > > > kern_addr_valid() and "(efault)" to alert user that something > > > is wrong instead of unecessarily panic the server. > > > > > > On the other hand, if the non-canonical string pointer is dereferenced > > > else where in the kernel, by virtue of being non-canonical, a crash > > > is expected to be immediate. > > > > What if there is no other dereference except the one happened in printf()? > > > > Just to point out here, that I formally NAKed this on the basis that NULL > > and error pointers are special, for the bogus pointers we need crash ASAP, > > no matter what the code issues it. I.o.w. printf() is not special for that > > kind of pointers (i.e. bogus pointers, but not special). > > Hey Andy, > > Do we want to have user space programs crash the kernel? > > This patch leads to making the kernel more harden so that we do > not crash when there are bugs but continue on. Fine, how to push a user to report a bug in the kernel if for them there is no bug? OK, let's assume user recognizes this as a bug, what should they do in order to provide a better description of the bug, so developer can easily debug and fix it? > Would we not want that experience for users ? Yes, if it is a bug in the kernel we want to know it with all possible details. Hiding bugs is a way to nowhere. -- With Best Regards, Andy Shevchenko