From: Vlastimil Babka <vbabka@suse.cz>
To: Sheng Yong <shengyong2021@gmail.com>,
akpm@linux-foundation.org, willy@infradead.org
Cc: linux-kernel@vger.kernel.org, linux-mm@archiver.kernel.org,
Sheng Yong <shengyong1@xiaomi.com>
Subject: Re: [PATCH v2] lib/iov_iter: fix to increase non slab folio refcount
Date: Tue, 1 Apr 2025 17:22:32 +0200 [thread overview]
Message-ID: <b2c07fdf-5ab1-4a65-9ce2-38638b7c718e@suse.cz> (raw)
In-Reply-To: <20250401144712.1377719-1-shengyong1@xiaomi.com>
On 4/1/25 16:47, Sheng Yong wrote:
> From: Sheng Yong <shengyong1@xiaomi.com>
>
> When testing EROFS file-backed mount over v9fs on qemu, I encountered
> a folio UAF issue. The page sanity check reports the following call
> trace. The root cause is that pages in bvec are coalesced across a folio
> bounary. The refcount of all non-slab folios should be increased to
> ensure p9_releas_pages can put them correctly.
>
> BUG: Bad page state in process md5sum pfn:18300
> page: refcount:0 mapcount:0 mapping:00000000d5ad8e4e index:0x60 pfn:0x18300
> head: order:0 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0
> aops:z_erofs_aops ino:30b0f dentry name(?):"GoogleExtServicesCn.apk"
> flags: 0x100000000000041(locked|head|node=0|zone=1)
> raw: 0100000000000041 dead000000000100 dead000000000122 ffff888014b13bd0
> raw: 0000000000000060 0000000000000020 00000000ffffffff 0000000000000000
> head: 0100000000000041 dead000000000100 dead000000000122 ffff888014b13bd0
> head: 0000000000000060 0000000000000020 00000000ffffffff 0000000000000000
> head: 0100000000000000 0000000000000000 ffffffffffffffff 0000000000000000
> head: 0000000000000010 0000000000000000 00000000ffffffff 0000000000000000
> page dumped because: PAGE_FLAGS_CHECK_AT_FREE flag(s) set
> Call Trace:
> dump_stack_lvl+0x53/0x70
> bad_page+0xd4/0x220
> __free_pages_ok+0x76d/0xf30
> __folio_put+0x230/0x320
> p9_release_pages+0x179/0x1f0
> p9_virtio_zc_request+0xa2a/0x1230
> p9_client_zc_rpc.constprop.0+0x247/0x700
> p9_client_read_once+0x34d/0x810
> p9_client_read+0xf3/0x150
> v9fs_issue_read+0x111/0x360
> netfs_unbuffered_read_iter_locked+0x927/0x1390
> netfs_unbuffered_read_iter+0xa2/0xe0
> vfs_iocb_iter_read+0x2c7/0x460
> erofs_fileio_rq_submit+0x46b/0x5b0
> z_erofs_runqueue+0x1203/0x21e0
> z_erofs_readahead+0x579/0x8b0
> read_pages+0x19f/0xa70
> page_cache_ra_order+0x4ad/0xb80
> filemap_readahead.isra.0+0xe7/0x150
> filemap_get_pages+0x7aa/0x1890
> filemap_read+0x320/0xc80
> vfs_read+0x6c6/0xa30
> ksys_read+0xf9/0x1c0
> do_syscall_64+0x9e/0x1a0
> entry_SYSCALL_64_after_hwframe+0x71/0x79
>
> Fixes: b9c0e49abfca ("mm: decline to manipulate the refcount on a slab page")
Sigh. That went to v6.14
mm-hotfixes and Cc: stable then?
> Signed-off-by: Sheng Yong <shengyong1@xiaomi.com>
Acked-by: Vlastimil Babka <vbabka@suse.cz>
Thanks.
> ---
> lib/iov_iter.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
> ---
> v2:
> * update commit message
> * update coding style
>
> diff --git a/lib/iov_iter.c b/lib/iov_iter.c
> index 8c7fdb7d8c8f..bc9391e55d57 100644
> --- a/lib/iov_iter.c
> +++ b/lib/iov_iter.c
> @@ -1191,7 +1191,7 @@ static ssize_t __iov_iter_get_pages_alloc(struct iov_iter *i,
> return -ENOMEM;
> p = *pages;
> for (int k = 0; k < n; k++) {
> - struct folio *folio = page_folio(page);
> + struct folio *folio = page_folio(page + k);
> p[k] = page + k;
> if (!folio_test_slab(folio))
> folio_get(folio);
next prev parent reply other threads:[~2025-04-01 15:22 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-01 14:47 Sheng Yong
2025-04-01 15:12 ` Matthew Wilcox
2025-04-01 15:22 ` Vlastimil Babka [this message]
2025-04-02 13:36 ` Sheng Yong
2025-04-02 13:45 ` Vlastimil Babka
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=b2c07fdf-5ab1-4a65-9ce2-38638b7c718e@suse.cz \
--to=vbabka@suse.cz \
--cc=akpm@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@archiver.kernel.org \
--cc=shengyong1@xiaomi.com \
--cc=shengyong2021@gmail.com \
--cc=willy@infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®