Received: by 2002:a25:ab43:0:0:0:0:0 with SMTP id u61csp7106611ybi; Thu, 13 Jun 2019 09:39:35 -0700 (PDT) X-Google-Smtp-Source: APXvYqzcvoqixWlsfhZH1PO+q3zs5BH557+ySHxEAmX0PW4i4TMBoMSFAMHcj8qNjnqbG1GMlyb9 X-Received: by 2002:a65:490f:: with SMTP id p15mr31434267pgs.275.1560443975704; Thu, 13 Jun 2019 09:39:35 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1560443975; cv=none; d=google.com; s=arc-20160816; b=jRVEVaGPlqnJtkTrzCzdrCNX1liX1LDYC1TCBlVbJ+jRw8K9lGDX4nVKmuKavGmOlx EVMWrBV2ltDEkcD+bOx2IoES21Y6DrNw8gB6CMtbtbSTvb+0UMr90GGAQmc4h42HHNKy HLXXUkwPqHCEtbgQC5DOhh3c3hcs0yP8tBwPKdGCDIkcPa9LqcgyiBR8tKp0tyVXPVDj 7ypRMfafY/WNdGqmphlBSWIgtp1KdUIeHFzDGnvyN4V0OVNzBvsaVuXnFxbNRpQQleaZ fOsG+ZcRlxAkPlmDUzuwjAtWQgmLU3QDyTiBmx+2D+NMvxtW9AhI8yjztbI7SPn89m7u 79ZQ== 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:to:subject; bh=0klQn5ySzeEawnJDhTovmEbEV6thriLUQzThfbijIJY=; b=lsHqhiVfHgnj0f6MWDCv3jrCKVrIgcGrzX4ZPFUiQDHDoLtM9eOvfxwPaZgPu1FmxR sg+5SSo/2Ghf/uuRGjH1f4pTojHZk5o24gXvr3XJv9zOMK6+WvOwRM1UN0/Rx4/Ay4Qe BbEmGEZMJuw+KF09ULYegPJKsslDoKM1hwV8jyVW5wWCCNy82evWQgZplPsCqEdW9oC7 vx2wHueIyDHOtGo/D6G3Qph4NL4BV7muZmtlEQFps/cPmRmANoLOkm8YGU4BxI2xIcRT FZAq9A2FxdjNjaW8tvi/tplU+2/KmjoXFc5b/vsjaBDpxD1roL03tyrtK/oZWcQzCLod PQGg== 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 c3si83891pfr.27.2019.06.13.09.39.20; Thu, 13 Jun 2019 09:39:35 -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 S2392767AbfFMQjP (ORCPT + 99 others); Thu, 13 Jun 2019 12:39:15 -0400 Received: from szxga05-in.huawei.com ([45.249.212.191]:18143 "EHLO huawei.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1730600AbfFMHJa (ORCPT ); Thu, 13 Jun 2019 03:09:30 -0400 Received: from DGGEMS411-HUB.china.huawei.com (unknown [172.30.72.59]) by Forcepoint Email with ESMTP id 1ABB06BE73A68DD261B2; Thu, 13 Jun 2019 15:09:28 +0800 (CST) Received: from [10.134.22.195] (10.134.22.195) by smtp.huawei.com (10.3.19.211) with Microsoft SMTP Server (TLS) id 14.3.439.0; Thu, 13 Jun 2019 15:09:25 +0800 Subject: Re: [PATCH] f2fs: add boundary check in inline_data_addr To: Randall Huang , , , References: <20190612085800.11947-1-huangrandall@google.com> From: Chao Yu Message-ID: Date: Thu, 13 Jun 2019 15:09:24 +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: <20190612085800.11947-1-huangrandall@google.com> Content-Type: text/plain; charset="utf-8" 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 Randall, On 2019/6/12 16:58, Randall Huang wrote: > Add boundary check in case of extra_size is larger > than sizeof array "i_addr" > > Signed-off-by: Randall Huang > --- > fs/f2fs/f2fs.h | 18 ++++++++++++++---- > 1 file changed, 14 insertions(+), 4 deletions(-) > > diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h > index 760390f380b6..17f3858a00c3 100644 > --- a/fs/f2fs/f2fs.h > +++ b/fs/f2fs/f2fs.h > @@ -2660,11 +2660,25 @@ static inline bool f2fs_is_drop_cache(struct inode *inode) > return is_inode_flag_set(inode, FI_DROP_CACHE); > } > > +#define F2FS_TOTAL_EXTRA_ATTR_SIZE \ > + (offsetof(struct f2fs_inode, i_extra_end) - \ > + offsetof(struct f2fs_inode, i_extra_isize)) \ > + > static inline void *inline_data_addr(struct inode *inode, struct page *page) > { > struct f2fs_inode *ri = F2FS_INODE(page); > int extra_size = get_extra_isize(inode); > > + if (extra_size < 0 || extra_size > F2FS_TOTAL_EXTRA_ATTR_SIZE || > + extra_size % sizeof(__le32)) { > + f2fs_msg(F2FS_I_SB(inode)->sb, KERN_ERR, > + "%s: inode (ino=%lx) has corrupted i_extra_isize: %d, " > + "max: %zu", > + __func__, inode->i_ino, extra_size, > + F2FS_TOTAL_EXTRA_ATTR_SIZE); > + extra_size = 0; > + } Oh, we have already did the sanity check on .i_extra_isize field in sanity_check_inode(), why can it be changed after that? bit-transition of cache or memory overflow? Thanks, > + > return (void *)&(ri->i_addr[extra_size + DEF_INLINE_RESERVED_SIZE]); > } > > @@ -2817,10 +2831,6 @@ static inline int get_inline_xattr_addrs(struct inode *inode) > ((is_inode_flag_set(i, FI_ACL_MODE)) ? \ > (F2FS_I(i)->i_acl_mode) : ((i)->i_mode)) > > -#define F2FS_TOTAL_EXTRA_ATTR_SIZE \ > - (offsetof(struct f2fs_inode, i_extra_end) - \ > - offsetof(struct f2fs_inode, i_extra_isize)) \ > - > #define F2FS_OLD_ATTRIBUTE_SIZE (offsetof(struct f2fs_inode, i_addr)) > #define F2FS_FITS_IN_INODE(f2fs_inode, extra_isize, field) \ > ((offsetof(typeof(*(f2fs_inode)), field) + \ >