Received: by 2002:a25:ab43:0:0:0:0:0 with SMTP id u61csp1340206ybi; Wed, 19 Jun 2019 18:48:34 -0700 (PDT) X-Google-Smtp-Source: APXvYqzwwD10GHHX10YhC2ogp2YDJaABuB4QMUri6zkhgTe1ko6P9gxZnC4YTgnwYo+PnMHrukk/ X-Received: by 2002:a63:3710:: with SMTP id e16mr10447666pga.391.1560995314739; Wed, 19 Jun 2019 18:48:34 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1560995314; cv=none; d=google.com; s=arc-20160816; b=sYLEPfdBogbaR/ZoTHycMRB/cg931fROhBuEtoS9h911JRacu70oUaYMV/pmZHJ9OL oliLn1P7eE71hlh10EaHvymbGeBjypsluZHmwxxpJNLlQYj/G20zzwQiIEz0/NnQ20O0 rPG1NT3w0BcdMLZOnYaIcTItelH8uCoIELX4iIOpAo5PUiVJYIcVGF1BrrdSipdiNq9l uRBxW81UpKeRuJulA/bBZz86D+bievLVAlN81zOGXs59gW7mwS93GcI8snHLt651aNL/ U9LH60+P/56NlD7QSBDKEHeK7qhfDMx52IYlmVQz7Ac+EGTCTRMQXOap3k5NL3dZ0532 kQyQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject; bh=kOV1G+pIs+qAhJdpiP3BRwmbO4zX4HA5cmuXuEE0nWg=; b=rmx7TEN2047iyvxii+O4ma0p3TR2KpnjLpSwzYc3SBc+1pri05zBOmK2DfrU7sqo8K pu2KNfcrCiu2jewhT0+9rojqtzbf92/F6ccEr7PlFR9dYufQ16DlJ5aqRLjL7ib1nfg9 VwnU+CcVibHAbPobKskTfSDTTgV0lxzT69SjEwhuvguANfJhJGVseSCWHWPNE0dR1cqE e82grT5ee6M1yeSzhaSszBClftnCJMdx8TXUHKd8Noduk6/jjeqAaPyFWhRkono0uQDg xYcxc3SWa1PTGhCTP6Fck6Bz0HlhRuLklCCBtwBul74J/jF/Zpk/0dRy31b4JNzU+pvk mFJQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id v24si7235453ply.101.2019.06.19.18.48.18; Wed, 19 Jun 2019 18:48:34 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731235AbfFTBqm (ORCPT + 99 others); Wed, 19 Jun 2019 21:46:42 -0400 Received: from szxga06-in.huawei.com ([45.249.212.32]:40124 "EHLO huawei.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726370AbfFTBqm (ORCPT ); Wed, 19 Jun 2019 21:46:42 -0400 Received: from DGGEMS402-HUB.china.huawei.com (unknown [172.30.72.60]) by Forcepoint Email with ESMTP id 0996FF91209E76EABC8A; Thu, 20 Jun 2019 09:46:40 +0800 (CST) Received: from [10.134.22.195] (10.134.22.195) by smtp.huawei.com (10.3.19.202) with Microsoft SMTP Server (TLS) id 14.3.439.0; Thu, 20 Jun 2019 09:46:35 +0800 Subject: Re: [PATCH 4.19 33/75] f2fs: fix to avoid accessing xattr across the boundary To: Pavel Machek CC: , Randall Huang , Jaegeuk Kim , Sasha Levin References: <20190617210752.799453599@linuxfoundation.org> <20190617210754.076823433@linuxfoundation.org> <20190619123210.GA14477@xo-6d-61-c0.localdomain> From: Chao Yu Message-ID: Date: Thu, 20 Jun 2019 09:46:35 +0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <20190619123210.GA14477@xo-6d-61-c0.localdomain> Content-Type: text/plain; charset="windows-1252" Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [10.134.22.195] X-CFilter-Loop: Reflected Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Pavel, On 2019/6/19 20:32, Pavel Machek wrote: > Hi! > >> When we traverse xattr entries via __find_xattr(), >> if the raw filesystem content is faked or any hardware failure occurs, >> out-of-bound error can be detected by KASAN. >> Fix the issue by introducing boundary check. > > Ok, so this prevents fs corruption from causing problems, > >> @@ -340,7 +347,11 @@ static int lookup_all_xattrs(struct inode *inode, struct page *ipage, >> else >> cur_addr = txattr_addr; >> >> - *xe = __find_xattr(cur_addr, index, len, name); >> + *xe = __find_xattr(cur_addr, last_txattr_addr, index, len, name); >> + if (!*xe) { >> + err = -EFAULT; >> + goto out; >> + } > > Is -EFAULT suitable here? We do not have userspace passing pointers to us, we > have fs corruption. -EUNCLEAN? Oh, right, f2fs uses -EFAULT as error number to indicate filesystem is corrupted all the time, we need to fix it to follow other generic fs. > > Should it do some kind of printk to let the user know fs is corrupted, and mark > it as needing fsck? Agreed, let me add it. :) Thanks, > > Thanks, > Pavel > . >