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 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 75D4CC433EF for ; Tue, 9 Nov 2021 02:33:12 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 27D7C611CC for ; Tue, 9 Nov 2021 02:33:12 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 27D7C611CC Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=linux-foundation.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id BC5366B00B3; Mon, 8 Nov 2021 21:33:11 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id B9B136B00B4; Mon, 8 Nov 2021 21:33:11 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A62E36B00B5; Mon, 8 Nov 2021 21:33:11 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0190.hostedemail.com [216.40.44.190]) by kanga.kvack.org (Postfix) with ESMTP id 905E66B00B3 for ; Mon, 8 Nov 2021 21:33:11 -0500 (EST) Received: from smtpin22.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 5E29718466DF3 for ; Tue, 9 Nov 2021 02:33:11 +0000 (UTC) X-FDA: 78787819782.22.13B79E3 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by imf06.hostedemail.com (Postfix) with ESMTP id 02CA9801AB35 for ; Tue, 9 Nov 2021 02:33:10 +0000 (UTC) Received: by mail.kernel.org (Postfix) with ESMTPSA id CF0AC60FC1; Tue, 9 Nov 2021 02:33:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1636425190; bh=0LHtt6hKjULTF8OWDJhcEcC9QHkxNvSszONB67A6Tuo=; h=Date:From:To:Subject:In-Reply-To:From; b=njvUSN3fr61JMeY7GQ36jk5XZ6kZi70nytuBiWMx8I3S24MMGoRz/CJS4o0hRQii6 OOszOa8xuiaPcWSS/fpoyfUrGBELqzLgvK0uRaR8VdVm3BgDphwrzex9JkOjGOjIFr DH4L4pPJK6gzX+57QZg4baLpENj20xqxixOKu1mE= Date: Mon, 08 Nov 2021 18:33:09 -0800 From: Andrew Morton To: airlied@linux.ie, akpm@linux-foundation.org, andreyknvl@gmail.com, daniel@ffwll.ch, dvyukov@google.com, geert@linux-m68k.org, glider@google.com, imran.f.khan@oracle.com, linux-mm@kvack.org, maarten.lankhorst@linux.intel.com, mm-commits@vger.kernel.org, mripard@kernel.org, ryabinin.a.a@gmail.com, torvalds@linux-foundation.org, tzimmermann@suse.de, vbabka@suse.cz Subject: [patch 33/87] lib, stackdepot: check stackdepot handle before accessing slabs Message-ID: <20211109023309.Nr_R0YRU6%akpm@linux-foundation.org> In-Reply-To: <20211108183057.809e428e841088b657a975ec@linux-foundation.org> User-Agent: s-nail v14.8.16 Authentication-Results: imf06.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b=njvUSN3f; spf=pass (imf06.hostedemail.com: domain of akpm@linux-foundation.org designates 198.145.29.99 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org; dmarc=none X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 02CA9801AB35 X-Stat-Signature: 9gbz5j41473ofxa3roo71kie75ryutzx X-HE-Tag: 1636425190-460196 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: From: Imran Khan Subject: lib, stackdepot: check stackdepot handle before accessing slabs Patch series "lib, stackdepot: check stackdepot handle before accessing slabs", v2. PATCH-1: Checks validity of a stackdepot handle before proceeding to access stackdepot slab/objects. PATCH-2: Adds a helper in stackdepot, to allow users to print stack entries just by specifying the stackdepot handle. It also changes such users to use this new interface. PATCH-3: Adds a helper in stackdepot, to allow users to print stack entries into buffers just by specifying the stackdepot handle and destination buffer. It also changes such users to use this new interface. This patch (of 3): stack_depot_save allocates slabs that will be used for storing objects in future.If this slab allocation fails we may get to a situation where space allocation for a new stack_record fails, causing stack_depot_save to return 0 as handle. If user of this handle ends up invoking stack_depot_fetch with this handle value, current implementation of stack_depot_fetch will end up using slab from wrong index. To avoid this check handle value at the beginning. Link: https://lkml.kernel.org/r/20210915175321.3472770-1-imran.f.khan@oracle.com Link: https://lkml.kernel.org/r/20210915014806.3206938-1-imran.f.khan@oracle.com Link: https://lkml.kernel.org/r/20210915014806.3206938-2-imran.f.khan@oracle.com Signed-off-by: Imran Khan Suggested-by: Vlastimil Babka Acked-by: Vlastimil Babka Cc: Geert Uytterhoeven Cc: Andrey Ryabinin Cc: Alexander Potapenko Cc: Andrey Konovalov Cc: Dmitry Vyukov Cc: Maarten Lankhorst Cc: Maxime Ripard Cc: Thomas Zimmermann Cc: David Airlie Cc: Daniel Vetter Signed-off-by: Andrew Morton --- lib/stackdepot.c | 3 +++ 1 file changed, 3 insertions(+) --- a/lib/stackdepot.c~lib-stackdepot-check-stackdepot-handle-before-accessing-slabs +++ a/lib/stackdepot.c @@ -231,6 +231,9 @@ unsigned int stack_depot_fetch(depot_sta struct stack_record *stack; *entries = NULL; + if (!handle) + return 0; + if (parts.slabindex > depot_index) { WARN(1, "slab index %d out of bounds (%d) for stack id %08x\n", parts.slabindex, depot_index, handle); _