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 9A0F7C433FE for ; Wed, 19 Oct 2022 20:33:55 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 238076B0072; Wed, 19 Oct 2022 16:33:55 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 1F1AB6B0073; Wed, 19 Oct 2022 16:33:55 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0B08D6B0074; Wed, 19 Oct 2022 16:33:55 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id EC6D96B0072 for ; Wed, 19 Oct 2022 16:33:54 -0400 (EDT) Received: from smtpin16.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id C198CA0181 for ; Wed, 19 Oct 2022 20:33:54 +0000 (UTC) X-FDA: 80038850388.16.AF55D7D Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by imf21.hostedemail.com (Postfix) with ESMTP id 0BE481C0031 for ; Wed, 19 Oct 2022 20:33:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1666211634; x=1697747634; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=kbOO8HXCNH/9sysdQIqYNZClN/RyYEn/FyixWYB4ieM=; b=mDBYhL+5HjR3B7FEPrE7jRUsGiQ+XZLkw/YVaCoDeyc7+eCHPs3qNyrc eOiGWeAU6944A3vI4wVslwYd51iRBcwO9lTECWj2IQGxNUpDb9yGNQs2z hYGje+QEwPCIfwNC3PgtScKNAWf5IfUkMOehienL3rIkIyd+wautHd7vt dhhy5up66B4BtaBM9hXRDvI0TtViwdmnspnamMNCbKNJea8kJUh0WqlD7 vgc2jCBBlCRG9NP0MpkHssxyM51bUlAjbsWIeG1vJ9DqXgj6ukTNYf85s +kDRQ2WfrNZf0lLVpuRJ8pB+Zy5DkybaEUlGBHDJev69nSwTt/QXJEfUn w==; X-IronPort-AV: E=McAfee;i="6500,9779,10505"; a="308207854" X-IronPort-AV: E=Sophos;i="5.95,196,1661842800"; d="scan'208";a="308207854" Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by orsmga103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 19 Oct 2022 13:33:52 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6500,9779,10505"; a="718658950" X-IronPort-AV: E=Sophos;i="5.95,196,1661842800"; d="scan'208";a="718658950" Received: from smile.fi.intel.com ([10.237.72.54]) by FMSMGA003.fm.intel.com with ESMTP; 19 Oct 2022 13:33:49 -0700 Received: from andy by smile.fi.intel.com with local (Exim 4.96) (envelope-from ) id 1olFl5-00A7Lo-1i; Wed, 19 Oct 2022 23:33:47 +0300 Date: Wed, 19 Oct 2022 23:33:47 +0300 From: Andy Shevchenko To: Jane Chu Cc: 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, konrad.wilk@oracle.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: <20221019194159.2923873-1-jane.chu@oracle.com> Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1666211634; 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=59yypYwGq+5rt2qrMNR0hI1+DK3mqIRYy9D3YMhoFG4=; b=1R5WGDMvFJA3hV8giCn4OOmYl7xjacALbOjjvKngxnVclbTD+lDKX2eorHYXJratW9VTqh VTNL8iXYqNieFmJ/oh5NJklLK3E1qp7VjVwtWWJD95m+s5xxrrzGnAAR43z82TsWq12VwS T8jZ+Wy4Mekn1W5dNCdyUoh0vOXHRHM= ARC-Authentication-Results: i=1; imf21.hostedemail.com; dkim=none ("invalid DKIM record") header.d=intel.com header.s=Intel header.b=mDBYhL+5; spf=none (imf21.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; dmarc=fail reason="No valid SPF" header.from=intel.com (policy=none) ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1666211634; a=rsa-sha256; cv=none; b=tomP1aKI/WYY0R+6SRpUwH8IIiLlG2KqC9Z5+6QX0ifPXyjzYC6InG+ibbFRuGpJo6Wign wKtXxRk2QlYg/N/EjjfHvMtmX57t64aUkqwuEXmiqNCs58Hg3ipLDAGUuLwhf/NS/NWYW+ 22gGZeRrWY4crrD9Uh7K98tJVHLwOVo= X-Rspamd-Server: rspam12 X-Rspam-User: Authentication-Results: imf21.hostedemail.com; dkim=none ("invalid DKIM record") header.d=intel.com header.s=Intel header.b=mDBYhL+5; spf=none (imf21.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; dmarc=fail reason="No valid SPF" header.from=intel.com (policy=none) X-Stat-Signature: mzdp65egafe88qynrf6bezjw5fnr3k8r X-Rspamd-Queue-Id: 0BE481C0031 X-HE-Tag: 1666211633-214349 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 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). -- With Best Regards, Andy Shevchenko