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=-6.8 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI, SIGNED_OFF_BY,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 812A1C32792 for ; Thu, 3 Oct 2019 10:19:15 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 564CF218DE for ; Thu, 3 Oct 2019 10:19:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1570097955; bh=WEV+2CFYjFrMoHL525sDDodxjUwFMneCYGCfKq+MLp4=; h=Subject:To:Cc:From:Date:List-ID:From; b=Mhm0IhGaV6ROW4OS1CgZtBXqKH3iFWrpaZ0wd/BdY4H5P1Aszw1itd938vWTl7k3o MNqhygCSxCXnTimWJiZMEjjBgWW611X747wkUIPZ++4iBaNcqAO6Vjt8Jay4y/P4fp JET3LCdu3OeZTKPEEHp4UD0vp2yrwE3JsEAal3ro= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727410AbfJCKTP (ORCPT ); Thu, 3 Oct 2019 06:19:15 -0400 Received: from out1-smtp.messagingengine.com ([66.111.4.25]:41581 "EHLO out1-smtp.messagingengine.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726808AbfJCKTO (ORCPT ); Thu, 3 Oct 2019 06:19:14 -0400 Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 8BE5621EC3; Thu, 3 Oct 2019 06:19:13 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute6.internal (MEProxy); Thu, 03 Oct 2019 06:19:13 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=Dq1Yz+ KGedL3Ko+m+WXzoB03l3f+KYUsCHJ9xviWabA=; b=diy+in6tkQxdiRJprx4zs+ hmdWWZk0OWJglP47Et51sdr4zfQVRrmZPWCfGbzqOwQJ379C5q6rQcX02tVv99QS G7lUjF5smZDK0NceopDOTDOGjzWl/xUOyH9OmoHJkUqH2ZlB7FidSgaYZUn/S+bx PQ00ej0vN+kQHQ4hLuQL8jGFyKkxAi5APS3fEAzABLms1B4s4pRCvREfjce4CmEt 86GOpDN85tkdi5mnRq+Axg5DCDr4jV6ne2csvu44b+g8xQ5LpvyE5FmGedRYEon1 AnyWpvetVxRYV5RFls0iQTLOXxggdyfHBsYTn6adt3dvlcUCERGGcwJvVCbK6yiQ == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrgeekgddviecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepuffvhfffkfggtgfgsehtkeertddttd flnecuhfhrohhmpeeoghhrvghgkhhhsehlihhnuhigfhhouhhnuggrthhiohhnrdhorhhg qeenucffohhmrghinhepkhgvrhhnvghlrdhorhhgnecukfhppeekfedrkeeirdekledrud dtjeenucfrrghrrghmpehmrghilhhfrhhomhepghhrvghgsehkrhhorghhrdgtohhmnecu vehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: from localhost (83-86-89-107.cable.dynamic.v4.ziggo.nl [83.86.89.107]) by mail.messagingengine.com (Postfix) with ESMTPA id A7739D6005A; Thu, 3 Oct 2019 06:19:12 -0400 (EDT) Subject: FAILED: patch "[PATCH] staging: erofs: fix an error handling in erofs_readdir()" failed to apply to 4.19-stable tree To: gaoxiang25@huawei.com, gregkh@linuxfoundation.org, richard@nod.at, stable@vger.kernel.org, yuchao0@huawei.com Cc: From: Date: Thu, 03 Oct 2019 12:19:11 +0200 Message-ID: <1570097951151216@kroah.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ANSI_X3.4-1968 Content-Transfer-Encoding: 8bit Sender: stable-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org The patch below does not apply to the 4.19-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to . thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From acb383f1dcb4f1e79b66d4be3a0b6f519a957b0d Mon Sep 17 00:00:00 2001 From: Gao Xiang Date: Sun, 18 Aug 2019 20:54:57 +0800 Subject: [PATCH] staging: erofs: fix an error handling in erofs_readdir() Richard observed a forever loop of erofs_read_raw_page() [1] which can be generated by forcely setting ->u.i_blkaddr to 0xdeadbeef (as my understanding block layer can handle access beyond end of device correctly). After digging into that, it seems the problem is highly related with directories and then I found the root cause is an improper error handling in erofs_readdir(). Let's fix it now. [1] https://lore.kernel.org/r/1163995781.68824.1566084358245.JavaMail.zimbra@nod.at/ Reported-by: Richard Weinberger Fixes: 3aa8ec716e52 ("staging: erofs: add directory operations") Cc: # 4.19+ Reviewed-by: Chao Yu Signed-off-by: Gao Xiang Link: https://lore.kernel.org/r/20190818125457.25906-1-hsiangkao@aol.com Signed-off-by: Greg Kroah-Hartman diff --git a/drivers/staging/erofs/dir.c b/drivers/staging/erofs/dir.c index 5f38382637e6..77ef856df9f3 100644 --- a/drivers/staging/erofs/dir.c +++ b/drivers/staging/erofs/dir.c @@ -82,8 +82,15 @@ static int erofs_readdir(struct file *f, struct dir_context *ctx) unsigned int nameoff, maxsize; dentry_page = read_mapping_page(mapping, i, NULL); - if (IS_ERR(dentry_page)) - continue; + if (dentry_page == ERR_PTR(-ENOMEM)) { + err = -ENOMEM; + break; + } else if (IS_ERR(dentry_page)) { + errln("fail to readdir of logical block %u of nid %llu", + i, EROFS_V(dir)->nid); + err = -EFSCORRUPTED; + break; + } de = (struct erofs_dirent *)kmap(dentry_page);