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=-5.3 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_PASS,USER_AGENT_MUTT 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 A2844C43441 for ; Thu, 11 Oct 2018 00:31:44 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 589A020644 for ; Thu, 11 Oct 2018 00:31:44 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 589A020644 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=intel.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726663AbeJKH4U (ORCPT ); Thu, 11 Oct 2018 03:56:20 -0400 Received: from mga03.intel.com ([134.134.136.65]:26527 "EHLO mga03.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726051AbeJKH4U (ORCPT ); Thu, 11 Oct 2018 03:56:20 -0400 X-Amp-Result: UNSCANNABLE X-Amp-File-Uploaded: False Received: from orsmga006.jf.intel.com ([10.7.209.51]) by orsmga103.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 10 Oct 2018 17:31:42 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.54,366,1534834800"; d="scan'208";a="81623903" Received: from sjchrist-coffee.jf.intel.com (HELO linux.intel.com) ([10.54.74.193]) by orsmga006.jf.intel.com with ESMTP; 10 Oct 2018 17:31:42 -0700 Date: Wed, 10 Oct 2018 17:31:42 -0700 From: Sean Christopherson To: "Eric W. Biederman" Cc: kernel test robot , linux-kernel@vger.kernel.org, LKP Subject: Re: [LKP] 4ce5f9c9e7 [ 1.323881] WARNING: CPU: 0 PID: 1 at mm/slab_common.c:1031 kmalloc_slab Message-ID: <20181011003141.GA25974@linux.intel.com> References: <20181010020641.GE13396@shao2-debian> <87sh1dvmc5.fsf@xmission.com> <87h8htv4lf.fsf@xmission.com> <20181010234148.GA25537@linux.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20181010234148.GA25537@linux.intel.com> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Oct 10, 2018 at 04:41:48PM -0700, Sean Christopherson wrote: > On Wed, Oct 10, 2018 at 05:06:52PM -0500, Eric W. Biederman wrote: > > ebiederm@xmission.com (Eric W. Biederman) writes: > > > > > So I am flummoxed. I am reading through the code and I don't see > > > anything that could trigger this, and when I ran the supplied reproducer > > > it did not reproduce for me. > > > > Even more so. With my tool chain the line that reports the failing > > address is impossible. > > > > [ 73.034423] RIP: 0010:copy_siginfo_from_user+0x4d/0xd0 > > > > With the supplied configureation my tool chain only has 0x30 bytes for > > all of copy_siginfo_from_user. So I can't even begin to guess where > > in that function things are failing. > > > > Any additional information that you can provide would be a real help > > in tracking down this strange failure. > > I don't have the exact toolchain, but I was able to get somewhat close > and may have found a smoking gun. 0x4d in my build is in the general > vicinity of "sig_sicodes[sig].limit" in known_siginfo_layout(). This > lines up with the register state from the log, e.g. RDI=0500104d8, > which is the mask generated by sig_specific_sicodes. From what I can > tell, @sig is never bounds checked. If the compiler generated an AND > instruction to compare against sig_specific_sicodes then that could > resolve true with any arbitrary value that happened to collide with > sig_specific_sicodes and result in an out-of-bounds access to > @sig_sicodes. siginfo_layout() for example explicitly checks @sig > before indexing @sig_sicode, e.g. "sig < ARRAY_SIZE(sig_sicodes)". Hmm, siginmask explicitly checks sig < SIGRTMIN, which might squash my theory. > > Maybe this? > > --- > kernel/signal.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/kernel/signal.c b/kernel/signal.c > index 1c2dd117fee0..6ee7491de906 100644 > --- a/kernel/signal.c > +++ b/kernel/signal.c > @@ -2865,7 +2865,8 @@ static bool known_siginfo_layout(int sig, int si_code) > if (si_code == SI_KERNEL) > return true; > else if ((si_code > SI_USER)) { > - if (sig_specific_sicodes(sig)) { > + if (sig < ARRAY_SIZE(sig_sicodes) && > + sig_specific_sicodes(sig)) { > if (si_code <= sig_sicodes[sig].limit) > return true; > }