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=-13.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=ham 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 3D841C83013 for ; Wed, 2 Dec 2020 17:21:37 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id F24D8221E9 for ; Wed, 2 Dec 2020 17:21:36 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2389151AbgLBRVC (ORCPT ); Wed, 2 Dec 2020 12:21:02 -0500 Received: from out03.mta.xmission.com ([166.70.13.233]:38674 "EHLO out03.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730822AbgLBRVB (ORCPT ); Wed, 2 Dec 2020 12:21:01 -0500 Received: from in02.mta.xmission.com ([166.70.13.52]) by out03.mta.xmission.com with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1kkVnf-0097Oh-0Y; Wed, 02 Dec 2020 10:20:19 -0700 Received: from ip68-227-160-95.om.om.cox.net ([68.227.160.95] helo=x220.xmission.com) by in02.mta.xmission.com with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1kkVnd-0086Cl-6E; Wed, 02 Dec 2020 10:20:18 -0700 From: ebiederm@xmission.com (Eric W. Biederman) To: Alakesh Haloi Cc: linux-kernel@vger.kernel.org, Christian Brauner , Oleg Nesterov , Kees Cook , Sargun Dhillon , Minchan Kim , Bernd Edlinger References: <20201201024811.GA72235@ip-172-31-62-0.us-west-2.compute.internal> Date: Wed, 02 Dec 2020 11:19:46 -0600 In-Reply-To: <20201201024811.GA72235@ip-172-31-62-0.us-west-2.compute.internal> (Alakesh Haloi's message of "Mon, 30 Nov 2020 18:48:11 -0800") Message-ID: <875z5kceh9.fsf@x220.int.ebiederm.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-XM-SPF: eid=1kkVnd-0086Cl-6E;;;mid=<875z5kceh9.fsf@x220.int.ebiederm.org>;;;hst=in02.mta.xmission.com;;;ip=68.227.160.95;;;frm=ebiederm@xmission.com;;;spf=neutral X-XM-AID: U2FsdGVkX1820JkN6MFT05hCDba9I20kjij8AgB5dfE= X-SA-Exim-Connect-IP: 68.227.160.95 X-SA-Exim-Mail-From: ebiederm@xmission.com Subject: Re: [PATCH] pid: add null pointer check in pid_nr_ns() X-SA-Exim-Version: 4.2.1 (built Sat, 08 Feb 2020 21:53:50 +0000) X-SA-Exim-Scanned: Yes (on in02.mta.xmission.com) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Alakesh Haloi writes: > There has been at least one occurrence where a null pointer derefernce > panic was seen with following stack trace. > > #0 [ffffff800bcd3800] machine_kexec at ffffff8008095fb4 > #1 [ffffff800bcd3860] __crash_kexec at ffffff8008122a30 > #2 [ffffff800bcd39f0] panic at ffffff80080aa054 > #3 [ffffff800bcd3ae0] die at ffffff800808aee8 > #4 [ffffff800bcd3b20] die_kernel_fault at ffffff8008099520 > #5 [ffffff800bcd3b50] __do_kernel_fault at ffffff8008098e50 > #6 [ffffff800bcd3b80] do_translation_fault at ffffff800809929c > #7 [ffffff800bcd3b90] do_mem_abort at ffffff8008081204 > #8 [ffffff800bcd3d90] el1_ia at ffffff800808304c > PC: ffffff80080c20ec [pid_nr_ns+4] > LR: ffffff80080c231c [__task_pid_nr_ns+72] > SP: ffffff800bcd3da0 PSTATE: 60000005 > X29: ffffff800bcd3da0 X28: ffffffc00691c380 X27: 0000000000000001 > X26: 00000000004ce8e8 X25: 00000000004ce8d0 X24: ffffffc00691c3e0 > X23: ffffffc004e8c000 X22: 0000000000000000 X21: ffffffc00b042ed2 > X20: ffffff800876a4f0 X19: 0000000000000000 X18: 0000000000000000 > X17: 0000000000000001 X16: 0000000000000000 X15: 0000000000000000 > X14: 0000000400000003 X13: 0000000000000008 X12: fefefefefefefeff > X11: 0000000000000000 X10: 0000007fffffffff X9: 00000000004ce8b0 > X8: 00000000004ce8b0 X7: 0000000000000000 X6: ffffffc00b042ed2 > X5: ffffffc00b042ed2 X4: 0000000000020008 X3: 53206e69616c702f > X2: ffffff800876a4f0 X1: ffffff800876a4f0 X0: 53206e69616c702f > #9 [ffffff800bcd3da0] pid_nr_ns at ffffff80080c20e8 I just skimmed through the callers of pid_nr_ns and now I am very puzzled. I don't see any of them where the namespace can be passed as NULL. So I really suspect you have a larger but somewhere in the caller of pid_nr_ns. Perhaps the memory was stomped and you were lucky it was NULL. Without some more details I really don't think testing for a NULL namespace is useful or productive. At best it will mask bugs in the callers Eric > Signed-off-by: Alakesh Haloi > Cc: stable@vger.kernel.org > --- > kernel/pid.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/kernel/pid.c b/kernel/pid.c > index a96bc4bf4f86..3767b9e1431d 100644 > --- a/kernel/pid.c > +++ b/kernel/pid.c > @@ -474,7 +474,7 @@ pid_t pid_nr_ns(struct pid *pid, struct pid_namespace *ns) > struct upid *upid; > pid_t nr = 0; > > - if (pid && ns->level <= pid->level) { > + if (pid && ns && ns->level <= pid->level) { > upid = &pid->numbers[ns->level]; > if (upid->ns == ns) > nr = upid->nr;