Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
From:   Imran Khan <imran.f.khan@oracle.com>
To:     vbabka@suse.cz, geert@linux-m68k.org, akpm@linux-foundation.org,
        ryabinin.a.a@gmail.com, glider@google.com, andreyknvl@gmail.com,
        dvyukov@google.com, maarten.lankhorst@linux.intel.com,
        mripard@kernel.org, tzimmermann@suse.de, airlied@linux.ie,
        daniel@ffwll.ch
Cc:     dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org,
        intel-gfx@lists.freedesktop.org, linux-mm@kvack.org
Subject: [PATCH RESEND 1/3] lib, stackdepot: check stackdepot handle before accessing slabs.
Date:   Wed, 15 Sep 2021 11:48:04 +1000
Message-Id: <20210915014806.3206938-2-imran.f.khan@oracle.com>
In-Reply-To: <20210915014806.3206938-1-imran.f.khan@oracle.com>
References: <20210915014806.3206938-1-imran.f.khan@oracle.com>
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?A1bPdLn+D0iT9oFWnEnYIGyU/lLmNaAr/56ll0nXp9tBj6YfhJN0JOqeodoB?=
 =?us-ascii?Q?L/BaxwRxU6awo5XA2GNN4lVsE3SvxDHQ/0OFenzWbkzJJu2v0+A0ApubDD+l?=
 =?us-ascii?Q?6Th5EKXf9tD6UmHVJ8UQz+uIEB6ScKr3x8mXa8UMv0ckowqmCiBraGFmK6eB?=
 =?us-ascii?Q?ojEH+Gnc682SbHieecBcVFe06/hV4s18/O8A7F3l/SICt0LfG4WY0Ak7HubI?=
 =?us-ascii?Q?NrifMHcNyXkZ643QMkCkmDarxupm4NvI130HU6KQEVxj3vC5T1fQ+3h5Z57A?=
 =?us-ascii?Q?SyDOsG0gLMdXwmkeueUCOWHMFDHBh2J5fYWgdGmNUqjlSjRqQw9SOlzUDyBS?=
 =?us-ascii?Q?LSHEbX6weDHEHA8ByUY7z1f352jsndd3yHt3mLYscPRgxkLU3X4V8PnQTOp9?=
 =?us-ascii?Q?gsB9J4qyNZRoPs5NrkvlgRtMwAAYqCcSOwS5z6M9sqbv448Wca9AvMXjjSwh?=
 =?us-ascii?Q?gKFJSHDks8lom8IZtZMb8tkxiVXRry9OqkWveRMWTkdGDbX5GtppqCczduSX?=
 =?us-ascii?Q?gn7Q8Ydsbx5ipW1auduGpbuRcQXxA8KJdWjpZP4/Ac3xdegodY85OfdFUnFS?=
 =?us-ascii?Q?HHab2ItY1/rV63V9VYfnO56smhfbvN1wHYVfhSsDC9P2AY5Eo4SZGBcFrF3H?=
 =?us-ascii?Q?2mheHnr/0CIzth0K5h5Biy+WskAQi/sdzN5g6aVMYkIwh8sICmBWaur1ElXH?=
 =?us-ascii?Q?AZElpoKr7r+pt20MaeJgRuYBN9OeEordYSQxIhasYjLLtFRGuMfg5gjBqRCr?=
 =?us-ascii?Q?AiNjs64POCKE2dh4VdHCLgs+I7rMxQBNuXIeRyblrII+JvfaGXOswyReVHnx?=
 =?us-ascii?Q?EGsbu6zyWsdSIRm7H7QPCDcO9vl3ZNP89WZfNsRlPVp2F/m/TYh6PlQpS8Xj?=
 =?us-ascii?Q?4eGZYQDP04rCryW1pcaGEc1QnonB/denfSWrKXPNhBbWbRuKl7pC+g8sK+ku?=
 =?us-ascii?Q?38Hey65MalHaDNkSIJuicJe225omqx68h7jqPuOOF2LNHCE9uy/7hUXwz15O?=
 =?us-ascii?Q?VjJrFYZCfJsPyoFzevOGYruJdnlSmR66KhuXx8eJeS+k8bxUW30/uGWMVKID?=
 =?us-ascii?Q?OZI1Nn5APrHq0yiFX3Y4wy5Z0p0MwLbz0gGH8yx8bRBvRI02EU2O60Lk6a+U?=
 =?us-ascii?Q?dwf17c9KvRmeDnziaiV1thKeXa0D9O7ccb5RKiFxfjtbxMTFAMA70abhI/AD?=
 =?us-ascii?Q?cW4uQMsUpwsuV4cShxeToWNyeF5TVfjsIZEzy0E8AdMk10HKggIQRoIBs/au?=
 =?us-ascii?Q?bIBTdlSTK2YOR2PMwgKWppqShgyGmpqE4UCgDXyo674M5FL0K3buDiBWMpR4?=
 =?us-ascii?Q?bIryKbgvNIajKODtLbZP6wg7?=
X-OriginatorOrg: oracle.com
X-MS-Exchange-CrossTenant-Network-Message-Id: ab695376-890f-4571-7ef2-08d977eae3c4
X-MS-Exchange-CrossTenant-AuthSource: CO1PR10MB4468.namprd10.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 15 Sep 2021 01:48:18.0299
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: FJc5RPVxjWnkugCi4qjIG4Gprb0X/JHywoZuH2po+P0m5L4vfeqOshk08yvlcySYLMNf3kJdtkPNc2K02Tg/hg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR10MB4577
X-Proofpoint-Virus-Version: vendor=nai engine=6300 definitions=10107 signatures=668682
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxscore=0 adultscore=0 phishscore=0
 mlxlogscore=999 suspectscore=0 spamscore=0 bulkscore=0 malwarescore=0
 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2109030001
 definitions=main-2109150008
X-Proofpoint-ORIG-GUID: njEqINB1AZsZzz96KfLP4lMeuopx5NwH
X-Proofpoint-GUID: njEqINB1AZsZzz96KfLP4lMeuopx5NwH
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

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.

Signed-off-by: Imran Khan <imran.f.khan@oracle.com>
Suggested-by: Vlastimil Babka <vbabka@suse.cz>

Acked-by: Vlastimil Babka <vbabka@suse.cz>
---
 lib/stackdepot.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/lib/stackdepot.c b/lib/stackdepot.c
index 0a2e417f83cb..67439c082490 100644
--- a/lib/stackdepot.c
+++ b/lib/stackdepot.c
@@ -232,6 +232,9 @@ unsigned int stack_depot_fetch(depot_stack_handle_t handle,
 	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);
-- 
2.30.2