From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out30-119.freemail.mail.aliyun.com (out30-119.freemail.mail.aliyun.com [115.124.30.119]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 6897B2D1F40 for ; Wed, 20 May 2026 04:25:38 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=115.124.30.119 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779251142; cv=none; b=CaWyrJx8KoYlTqgmiZ7BZeExODcF5CgbaDw3x6+xfL0IJBaH1oAprdlkOoD8jkgVGQUp+6CGJqOwwP3H8W7n2fKwaHJEN+HpJp0IITeHx2IsMnC18HHM/kHyMkfCa7y0Ufghfauzw05CHDf4rwzPM21mh8D73B03dlvfXsRVXk4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779251142; c=relaxed/simple; bh=/d7/L974Qi+2fgrSky8t4HOA0OAOYfLerZZpf+JXWWM=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=IER5fAdM1wqAkZDmg17SoevrgVBWzNAFAnqEvp6y0Q7HfB2Ag42zKjCaSgPwd3GgHdsRlVfiXR5DUoAETIZeWdaFV5pavcCoww4XIjcSbObu9+lpz3kNK4tDvX+hPq6CZZafaToT4K9Ua4sVD6Lv+m0YlKgVciqhGb0dyYHCVvs= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.alibaba.com; spf=pass smtp.mailfrom=linux.alibaba.com; dkim=pass (1024-bit key) header.d=linux.alibaba.com header.i=@linux.alibaba.com header.b=GbLTgse4; arc=none smtp.client-ip=115.124.30.119 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.alibaba.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.alibaba.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.alibaba.com header.i=@linux.alibaba.com header.b="GbLTgse4" DKIM-Signature:v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.alibaba.com; s=default; t=1779251130; h=Message-ID:Date:MIME-Version:Subject:To:From:Content-Type; bh=vBprvAeKPUGahtI2gP0STxTFpen0ySDLXfvesc2LssI=; b=GbLTgse4yDpQofnKOSpZBskvSVqueANOfJtMpHirw08bntLAaqPIhV4fupUZ0pSLCROOInfdPWivJwBHW4o2ja2NqZyflmUAo+8Gf9chwCxl5NxbB4k/hqkXdYBt6EgDKtJmUKnoPZ0fPCZxHzxN5bwydMxutil4mDIJcqMT6ec= X-Alimail-AntiSpam:AC=PASS;BC=-1|-1;BR=01201311R121e4;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=maildocker-contentspam033037009110;MF=hsiangkao@linux.alibaba.com;NM=1;PH=DS;RN=11;SR=0;TI=SMTPD_---0X3HHeIg_1779251129; Received: from 30.221.132.121(mailfrom:hsiangkao@linux.alibaba.com fp:SMTPD_---0X3HHeIg_1779251129 cluster:ay36) by smtp.aliyun-inc.com; Wed, 20 May 2026 12:25:30 +0800 Message-ID: Date: Wed, 20 May 2026 12:25:28 +0800 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] erofs: fix metabuf leak in shared xattr initialization To: Jia Zhu , Gao Xiang , Chao Yu Cc: linux-erofs@lists.ozlabs.org, linux-kernel@vger.kernel.org, Yue Hu , Jeffle Xu , Sandeep Dhavale , Hongbo Li , Chunhai Guo , Amir Goldstein References: <20260520034252.40163-1-zhujia.zj@bytedance.com> From: Gao Xiang In-Reply-To: <20260520034252.40163-1-zhujia.zj@bytedance.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Hi Jia, On 2026/5/20 11:42, Jia Zhu wrote: > erofs_init_inode_xattrs() uses a local metabuf while reading the inline > xattr header and the shared xattr id array. > > It currently drops that metabuf from some error paths and from the success > path, but the erofs_bread() failure while reading the shared xattr id array > goes straight to out_unlock. > > This became observable when file-backed metadata reads started calling > rw_verify_area() before reusing or dropping the current metabuf. Before > that, the read_mapping_folio() failure path already dropped the old metabuf > before returning an error. > > Consolidate the local metabuf cleanup at out_unlock. erofs_put_metabuf() > is a no-op if no page has been acquired, and this keeps all paths after > taking EROFS_I_BL_XATTR_BIT covered by one cleanup site. > > Fixes: 307210c262a2 ("erofs: verify metadata accesses for file-backed mounts") Hmm, I don't think it's a correct "Fixes:", and the commit message should be fixed too. I think it's an issue due to missing erofs_put_metabuf() in the erofs_init_inode_xattrs() error path instead. I think Fixes: bb88e8da0025 ("erofs: use meta buffers for xattr operations") is a more proper "Fixes:". Thanks, Gao Xiang > Signed-off-by: Jia Zhu > --- > fs/erofs/xattr.c | 4 +--- > 1 file changed, 1 insertion(+), 3 deletions(-) > > diff --git a/fs/erofs/xattr.c b/fs/erofs/xattr.c > index 41e311019a251..df7ea019526d7 100644 > --- a/fs/erofs/xattr.c > +++ b/fs/erofs/xattr.c > @@ -89,13 +89,11 @@ static int erofs_init_inode_xattrs(struct inode *inode) > vi->xattr_isize - sizeof(struct erofs_xattr_ibody_header)) { > erofs_err(sb, "invalid h_shared_count %u @ nid %llu", > vi->xattr_shared_count, vi->nid); > - erofs_put_metabuf(&buf); > ret = -EFSCORRUPTED; > goto out_unlock; > } > vi->xattr_shared_xattrs = kmalloc_objs(uint, vi->xattr_shared_count); > if (!vi->xattr_shared_xattrs) { > - erofs_put_metabuf(&buf); > ret = -ENOMEM; > goto out_unlock; > } > @@ -112,12 +110,12 @@ static int erofs_init_inode_xattrs(struct inode *inode) > } > vi->xattr_shared_xattrs[i] = le32_to_cpu(*xattr_id); > } > - erofs_put_metabuf(&buf); > > /* paired with smp_mb() at the beginning of the function. */ > smp_mb(); > set_bit(EROFS_I_EA_INITED_BIT, &vi->flags); > out_unlock: > + erofs_put_metabuf(&buf); > clear_and_wake_up_bit(EROFS_I_BL_XATTR_BIT, &vi->flags); > return ret; > }