Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Thu, 20 Oct 2022 10:52:03 -0400
From:   Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To:     Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc:     Jane Chu <jane.chu@oracle.com>, 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: <Y1Fgk1iDnhL7VtAl@char.us.oracle.com>
References: <20221019194159.2923873-1-jane.chu@oracle.com>
 <Y1BfK6LpDJDlUYKp@smile.fi.intel.com>
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Y1BfK6LpDJDlUYKp@smile.fi.intel.com>
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?KreLm34IZkU3xkDw3XptT3O9i8ZyxaZNYS+o+3hNrzNszFTM7moCIQf8uSUw?=
 =?us-ascii?Q?4yEws7xIkset+N+hN6TaA9G8EMa+GSMcdjXgQpOzz6kisabZl4lxl1YPX2ON?=
 =?us-ascii?Q?t9KjIahc70/Z8MQvJJt/FGXjCo7SlWOCrBifboau8lWfxQnPEXpMz/Qjwdfh?=
 =?us-ascii?Q?mMy7hAw0Ai6a3VVGL7K3LmW8x9hKzGftGNq93lE3pBUmEatHILsRoDcXACAb?=
 =?us-ascii?Q?JqBMntIbFAE3WjRNxJUrLtIzMva3qFPJqWnkeH2MU3FswQMhSSIC50V+vKHu?=
 =?us-ascii?Q?A0qiuASlG0Lg/m5isrPtNbQQqmfymduMhfAT+e1GFKeepoqdoV2Ud2TfBEkM?=
 =?us-ascii?Q?CyfBitUiEshEVeWzhFu4cANeDOBlXXuLgrlUiKQJ93yy5P3X3Xv8DNqQCX7W?=
 =?us-ascii?Q?DUX95uwl0JvaGYxnQjVsb48Q0htxjolrS8E5muXs0ZilAbwGKhh+McYDY2de?=
 =?us-ascii?Q?MqMfdNeyLUPWLMF/RP5tMs5FwiThWWSst5q0TAVqYiE1unzX6S6KiZos7T4Y?=
 =?us-ascii?Q?+BRAw+wt7qCSEn2hSOapkhfP4nZC5v3F25g3k0VCDxwW2IYc91PUYAZVf/Ho?=
 =?us-ascii?Q?A1NDf3YWoFVaxGV3/NYbLvk9J6XaYVTbcO5Je0WhrTK5oHTnl+6yXz4jjD6v?=
 =?us-ascii?Q?eHs7TJUgHTEnD5XKykC4iKw24SasIW7dNP3d1gNc8RTnmHCzq2VwK4SSg5hR?=
 =?us-ascii?Q?//GZHPxEDE6MhDczg7pmRoH1VxUEB5EhDW5tqhAnpW28iR9WFWAmLZRC3JtM?=
 =?us-ascii?Q?VDqM0neQiWl+yfNhHsDUY/FcOrHmJs+q6cEIiQGG+agjwBfF6v4IZTAEozzT?=
 =?us-ascii?Q?ebVdG9qkjFTbUvEaRLigv2YQPb7rBBDS5kp05vd+3L1HmoZBHYCcXyWP+AFn?=
 =?us-ascii?Q?qg8qOXVV+OdWeViwcSFYhUCPblF5obHm+2Q7DgVrXLYTNmoByPq9X94D0lWc?=
 =?us-ascii?Q?q+xaHNoClMr7UGxL5pUtfAKFK1u/saH1Vmn0Q8K90L01YLXbIf7Ab95WQ7fA?=
 =?us-ascii?Q?JRoIX8AvFpAZjrLwQoTKnrLhAUKhC3oXkkBH6wCFD/iIOl6Mu+xesk4VySPC?=
 =?us-ascii?Q?U+VGAuEJdjrWf30zwjY1aBfVwlmVmniKcKdKoJI1yKicb4M/8iObS2gi+O4c?=
 =?us-ascii?Q?pw8pSskmhr1UWgsuW8SeALtZu2lH+MKUPQRijZeMetiKciYh4PG23aQ7W+5B?=
 =?us-ascii?Q?LvJEZ7qujuS471EKhNNdtc7O8eWSbB7IC6Ek7BcwOTUAgFN0PvOPJjjbmxhv?=
 =?us-ascii?Q?K01aBVOHGG6LqtgMMF/9sPEu60XlLIhe7Ie3EMaD1OVvRpMuonEip6MR+nVy?=
 =?us-ascii?Q?xtO5hgyUKRq+1XaqbssafMsvxKiXoulyKzlC3SaGOsR3tQtETvPXdnm64SHc?=
 =?us-ascii?Q?OG217Y/2PrS+2f1XcdANl2V+LBIkrseDSmKFOznjCgtjzAiy+7L+ufTx6zfv?=
 =?us-ascii?Q?SI3knvC2m/afU8Mtf5b61SR1dJIxNxn54CnO32aJP6LoN/0FS1NLdrXFaX7o?=
 =?us-ascii?Q?cCJ7b+BxvFotissXwPxfiqvZiepr8bYDUOlawuFkpPPRnvDSZZfgE+DxcziZ?=
 =?us-ascii?Q?G0iRs4ULyMWYsexJwmccApGmmM4kYD/MJR3/Wbj+T5RQXCN0j1Ly4/uFi+04?=
 =?us-ascii?Q?RA=3D=3D?=
X-OriginatorOrg: oracle.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 0103de96-72be-4adf-53ec-08dab2aab2ae
X-MS-Exchange-CrossTenant-AuthSource: BYAPR10MB2999.namprd10.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Oct 2022 14:52:24.1737
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: kUavx/9uW44oZfpA07KkcKusMc6XwcN7ipqAWfIvxJbfe7+fmFlVDIi2DQtCs/97l53bEs3HPlbA6fCtDSx5Yw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLAPR10MB5218
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.205,Aquarius:18.0.895,Hydra:6.0.545,FMLib:17.11.122.1
 definitions=2022-10-20_06,2022-10-20_01,2022-06-22_01
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 adultscore=0 bulkscore=0
 malwarescore=0 phishscore=0 mlxlogscore=684 spamscore=0 mlxscore=0
 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2209130000
 definitions=main-2210200088
X-Proofpoint-ORIG-GUID: rkk5zapVj9BYrt1SxcoapYTHiScvZrYO
X-Proofpoint-GUID: rkk5zapVj9BYrt1SxcoapYTHiScvZrYO
X-Spam-Status: No, score=-2.8 required=5.0 tests=BAYES_00,DKIM_SIGNED,
        DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_LOW,
        RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE autolearn=ham
        autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
        lindbergh.monkeyblade.net
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

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.

Would we not want that experience for users ?
> 
> -- 
> With Best Regards,
> Andy Shevchenko
> 
>