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=-14.4 required=3.0 tests=DKIMWL_WL_MED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH, MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,USER_IN_DEF_DKIM_WL 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 14C33C432C3 for ; Wed, 27 Nov 2019 14:22:49 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id CAE0220722 for ; Wed, 27 Nov 2019 14:22:48 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="kzw2DRIF" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org CAE0220722 Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 626866B0499; Wed, 27 Nov 2019 09:22:48 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 5FDFA6B049A; Wed, 27 Nov 2019 09:22:48 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5158D6B049B; Wed, 27 Nov 2019 09:22:48 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 3AF086B0499 for ; Wed, 27 Nov 2019 09:22:48 -0500 (EST) Received: from smtpin30.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with SMTP id E4D6A8249980 for ; Wed, 27 Nov 2019 14:22:47 +0000 (UTC) X-FDA: 76202273574.30.quill13_5295e62cbf259 X-HE-Tag: quill13_5295e62cbf259 X-Filterd-Recvd-Size: 5705 Received: from mail-ot1-f65.google.com (mail-ot1-f65.google.com [209.85.210.65]) by imf36.hostedemail.com (Postfix) with ESMTP for ; Wed, 27 Nov 2019 14:22:47 +0000 (UTC) Received: by mail-ot1-f65.google.com with SMTP id n23so19210432otr.13 for ; Wed, 27 Nov 2019 06:22:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=HOtC8Y8IZ5493JuxNvS9OmXD9u7CTZ0LQWc4QZ2LetI=; b=kzw2DRIFWaha0y2E0+d9gea+1hcYNC+/aK3ZT3MooiscXW0/x600L9IdzkIKLvDYn7 yioJtS+SS2YMwGzso2bk3kdjbmbSx5tZklznxqZLHUjhuGUpDDcTF5NoQ/b3dHjiUMYF pa0DXYKx0iIrJCz2aZGucEzCWXcjFY71mpo0CGMImXi4schQwPyZbtBu8m3f91LLWMbH vObQ0gMFrEaSef82KNmpv7guQga1aUulTf21scakRUrtlwTdsLnYdd7hkRTPk1Ez6x8D do4pESx+mvad9jlUAVsuCSTn+BWQOPRW5E2AdYLwuY84m8BwiqPB/Tn3vZlFQKWbD1S2 hXDA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=HOtC8Y8IZ5493JuxNvS9OmXD9u7CTZ0LQWc4QZ2LetI=; b=rpKj14q/95olSW5UJLOPd4epW6e9kElqG/USCClNNZbSAWng0aGDeakkqcx3tN4rfa Ah0jQ68uuoXwDXr3BbVgJEYUGsy3MV0IXztahMhl/0snhoxQHQi8DiVNWW+Hj2Mx2QMc BdFd2H0g3yio+a/nkRq7BsBxtgI4fEFtkjazJKndiKUg5vTUyu1lTVmX4+6KPHobMVmg E/9+12fFPxD6xcsL4/5RZEkwpOedYAXrqXML56xHRAZHdNVItEhwy1IuD/wRcc9s8gtk dYJdLXAwOZV1Q95eA53lbvwCjftgeGtwgNZn1D+pVn2ZuXGTTxmbgASr+9VBWxazxZkr E18g== X-Gm-Message-State: APjAAAWRw3MyMsaOHyT9p4WbChkQYc3NqwHEXUHqKlC8LV+PuiEV2Uqh 98ynrJS9PtlppgKmbdYGSWlauTRxSO/Ao0C7JcLuxg== X-Google-Smtp-Source: APXvYqySRQ0liLmR4QrSJ3jRbbiLNDeXgxVw6hBHu0tGXL/hKqRJ11pA7IJBBgo6QPJMUo2t9hy3Y7FEVxdV5eJXdzE= X-Received: by 2002:a9d:605a:: with SMTP id v26mr3867350otj.23.1574864566138; Wed, 27 Nov 2019 06:22:46 -0800 (PST) MIME-Version: 1.0 References: <20191122112621.204798-1-glider@google.com> <20191122112621.204798-2-glider@google.com> In-Reply-To: <20191122112621.204798-2-glider@google.com> From: Marco Elver Date: Wed, 27 Nov 2019 15:22:33 +0100 Message-ID: Subject: Re: [PATCH RFC v3 01/36] stackdepot: check depot_index before accessing the stack slab To: Alexander Potapenko Cc: Vegard Nossum , Dmitry Vyukov , Linux Memory Management List , Al Viro , adilger.kernel@dilger.ca, Andrew Morton , Andrey Konovalov , Andrey Ryabinin , Andy Lutomirski , Ard Biesheuvel , Arnd Bergmann , hch@infradead.org, hch@lst.de, darrick.wong@oracle.com, davem@davemloft.net, dmitry.torokhov@gmail.com, ebiggers@google.com, Eric Dumazet , ericvh@gmail.com, gregkh@linuxfoundation.org, harry.wentland@amd.com, herbert@gondor.apana.org.au, iii@linux.ibm.com, mingo@elte.hu, jasowang@redhat.com, axboe@kernel.dk, m.szyprowski@samsung.com, Mark Rutland , martin.petersen@oracle.com, schwidefsky@de.ibm.com, Matthew Wilcox , mst@redhat.com, monstr@monstr.eu, pmladek@suse.com, Qian Cai , Randy Dunlap , robin.murphy@arm.com, sergey.senozhatsky@gmail.com, Steven Rostedt , tiwai@suse.com, tytso@mit.edu, Thomas Gleixner , gor@linux.ibm.com, wsa@the-dreams.de Content-Type: text/plain; charset="UTF-8" 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 Fri, 22 Nov 2019 at 12:26, wrote: > > Avoid crashes on corrupted stack ids. Under what circumstances can they be corrupted? > Signed-off-by: Alexander Potapenko > To: Alexander Potapenko > Cc: Vegard Nossum > Cc: Dmitry Vyukov > Cc: linux-mm@kvack.org > > --- > v3: > - fix the return statement > > Change-Id: I0a0b38ed5057090696a2c6ff0be7cfcc24ae6738 > --- > lib/stackdepot.c | 17 +++++++++++++++-- > 1 file changed, 15 insertions(+), 2 deletions(-) > > diff --git a/lib/stackdepot.c b/lib/stackdepot.c > index ed717dd08ff3..0bc6182bc7a6 100644 > --- a/lib/stackdepot.c > +++ b/lib/stackdepot.c > @@ -198,9 +198,22 @@ unsigned int stack_depot_fetch(depot_stack_handle_t handle, > unsigned long **entries) > { > union handle_parts parts = { .handle = handle }; > - void *slab = stack_slabs[parts.slabindex]; > + void *slab; > size_t offset = parts.offset << STACK_ALLOC_ALIGN; > - struct stack_record *stack = slab + offset; > + struct stack_record *stack; > + > + if (parts.slabindex > depot_index) { > + WARN(1, "slab index %d out of bounds (%d) for stack id %08x\n", > + parts.slabindex, depot_index, handle); On syzbot with panic_on_warn this will crash the kernel. Is this desirable? Or is a pr_err here more appropriate? > + *entries = NULL; > + return 0; > + } > + slab = stack_slabs[parts.slabindex]; > + stack = slab + offset; > + if (!stack) { > + entries = NULL; > + return 0; > + } > > *entries = stack->entries; > return stack->size; > -- > 2.24.0.432.g9d3f5f5b63-goog >