Received: by 10.213.65.68 with SMTP id h4csp1639373imn; Thu, 29 Mar 2018 08:17:39 -0700 (PDT) X-Google-Smtp-Source: AIpwx48Yy5kELU2l/D49FFJD9AOzrIQhMPPilFkMzYLRHs1fQLoVQKurTr61d7Ah0p5VrHVe18qi X-Received: by 2002:a17:902:680c:: with SMTP id h12-v6mr9148789plk.46.1522336659270; Thu, 29 Mar 2018 08:17:39 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1522336659; cv=none; d=google.com; s=arc-20160816; b=0R5MFoBN52XEBvrQMFlBgVKbMr644+ItwzM/j1EbPeeyPbMr+pYySayC4FnAc7u1ka a7nxuXx+uTxqfZJafFf2rgB1rIQ81xJh4yKqxOY31GzQyOm5qVdnXH4/IcS5GVRTN8I2 XzzN3oD8RHW1pQtonBmvaItvSnMV8nT9lL+dtvS1uiAum+7geZ+NjZX9QMmQ+hnWs5Nh 03G4kTveBt7yEhu5slqQNJCcf6Npc7Lo4QTxc3IkMtfNBoglFCyQwQV5Po+t942dKVc+ yMSx1tXSnXejg3Yc8AnTgwlvPjVJvXQvdk4e+eNAv4v/fh/zMRc33HG7pdFTTrWHHWPX eh0Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:arc-authentication-results; bh=XnmOHWgBg7m6Sv4FvoerHtw1+pDrY9hA3ri/iEnbsvI=; b=J+l+BafYZbY9NrMgM+7g26ObWjKKJp2EAieVWQJON5N6Cagh49hveXTLWrKFANO93F mflq26haky7+ntnXJ9S9CY8/WHCSukcXwwt8d9qPV537q+4/KzjTIfeA/toTqxJiH4oR p0R7oNVe79mVaA1CkjdUY+y75e246XFcg1b1ztCpJzpVy4+/KVTAQK0Ezce2HrT1lzYD 3a9La6hML0OSZCLYqmS1o0oj8BQQshWzHqV7zNDl0AFi0QPrh1jSrR+ZpMVNOIZrulDc ntSozAOUeBgDiH4AEyHy+KG9Q28pj3+R54UTzKOH5cP9jV0p2W3o6q8WyGR94KOXwXhO II7w== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id e1-v6si5826608pln.578.2018.03.29.08.16.55; Thu, 29 Mar 2018 08:17:39 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751859AbeC2PNM (ORCPT + 99 others); Thu, 29 Mar 2018 11:13:12 -0400 Received: from mx2.suse.de ([195.135.220.15]:59809 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751195AbeC2PNL (ORCPT ); Thu, 29 Mar 2018 11:13:11 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id DC831AC87; Thu, 29 Mar 2018 15:13:09 +0000 (UTC) Date: Thu, 29 Mar 2018 17:13:09 +0200 From: Petr Mladek To: Andy Shevchenko Cc: "Tobin C . Harding" , linux@rasmusvillemoes.dk, Joe Perches , linux-kernel@vger.kernel.org, Andrew Morton , Michal Hocko , Sergey Senozhatsky , Sergey Senozhatsky , Steven Rostedt Subject: Re: [PATCH] vsprintf: Make "null" pointer dereference more robust Message-ID: <20180329151309.omdoxcdku5xoshgx@pathway.suse.cz> References: <20180216210711.79901-1-andriy.shevchenko@linux.intel.com> <20180216210711.79901-8-andriy.shevchenko@linux.intel.com> <20180227155047.o74ohmoyj56up6pa@pathway.suse.cz> <1519752950.10722.231.camel@linux.intel.com> <20180228100437.o4juwxbzomkqjvjx@pathway.suse.cz> <1519814544.10722.266.camel@linux.intel.com> <20180302125118.bjd3tbuu72vgfczo@pathway.suse.cz> <20180302125359.szbin2kznxvoq7sc@pathway.suse.cz> <1520000254.10722.389.camel@linux.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1520000254.10722.389.camel@linux.intel.com> User-Agent: NeoMutt/20170421 (1.8.2) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri 2018-03-02 16:17:34, Andy Shevchenko wrote: > On Fri, 2018-03-02 at 13:53 +0100, Petr Mladek wrote: > > %p has many modifiers where the pointer is dereferenced. An invalid > > pointer might cause kernel to crash silently. > > > > Note that printk() formats the string under logbuf_lock. Any recursive > > printks are redirected to the printk_safe implementation and the > > messages > > are stored into per-CPU buffers. These buffers might be eventually > > flushed > > in printk_safe_flush_on_panic() but it is not guaranteed. > > > > In general, we should do our best to get useful message from printk(). > > All pointers to the first memory page must be invalid. Let's prevent > > the dereference and print "(null)" in this case. This is already done > > in many other situations, including "%s" format handling and many > > page fault handlers. > > > > > With such explanation it makes at least clear for the reader why it's > done. > > Thanks! > > Would you be okay if I take this one as a first in my series and > resubmit the series based on it? The original simple patch grew into something bigger. I have it almost ready. It looks the following way at the moment: vsprintf: Shuffle ptr_to_id() code vsprintf: Consistent %pK handling for kptr_restrict == 0 vsprintf: Do not check address of well-known strings vsprintf: Consolidate handling of unknown pointer specifiers vsprintf: Factor out %p[iI] handler as ip_addr_string() vsprintf: Factor out %pV handler as va_format() vsprintf: Factor out %pO handler as kobject_string() vsprintf: Prevent crash when dereferencing invalid pointers vsprintf: Avoid confusion between invalid address and value Documentation/core-api/printk-formats.rst | 8 + lib/test_printf.c | 37 ++- lib/vsprintf.c | 445 ++++++++++++++++++------------ 3 files changed, 307 insertions(+), 183 deletions(-) I still would like to do some final review and check with a fresh head after Easter holidays. Now, I am unsure how to merge it with your patchset. Most of your patches are independent and should be applied. But there will be some merge conflicts. On possibility would be that I take your still valid changes via printk.git. Then you would even need not send anything. I could resolve the conflicts when applying the patches. Or would you prefer to resend your patchset without the controversal check removal? And wait for my patchset? Best Regards, Petr