From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out30-112.freemail.mail.aliyun.com (out30-112.freemail.mail.aliyun.com [115.124.30.112]) (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 EAE4C382F0F; Tue, 24 Mar 2026 02:25:07 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=115.124.30.112 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774319111; cv=none; b=hWEEdtIKkc/guPGzzikrKPFdNzVVhZXqWHbCElcrasUiVGe+O9GoJ58yOOZIssY0hx/Nh6ZEJYOCmPK57W+ECBIrmqssJPiHO/oR5z3UdOTje9W6oJi9dEcDXV+OqKSH4E+qzS7OrQvDl37hmv+1mZCAP5OWLsI51NNNQb7gJTA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774319111; c=relaxed/simple; bh=DmxDr4071s0WPmReq2f42kbDuNSLqAeoRldhX5MLt6E=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=B5f4SyPqCedKrXJJK7ra/b+BzFLSrMZEKFfjEdLSKvklHEHe21n7ZS7fROHWPKJq/dXEtE5GC3oRtUHd0n2E8EhDMMo0rVQx7WkigV8725khW5xNzm/FL9waIDj+zyEg6PkxzYjdVkbSIFEmdjKg1z3nvksWzOQ3rGoFcSjMO58= 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=edzDOKCJ; arc=none smtp.client-ip=115.124.30.112 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="edzDOKCJ" DKIM-Signature:v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.alibaba.com; s=default; t=1774319101; h=Message-ID:Date:MIME-Version:Subject:To:From:Content-Type; bh=WpN0mI+CiekGT3pQv7cElpiCqSQyUImlVpSl4bDuZNI=; b=edzDOKCJcO7VMjkQHufe1syvSFavowfZ7lQJNTcdMBtGjAYPzcjRlEw4F//yTlZOpYg/w/aykiaJCx3Q5qyQ1uE4KUr1cXnZRKjZaygeD0aD4ECJZQvI0w0vAfaV+7yvEjl39CAUoAP3fOLjpz6abk22p0evOGbQoaY5Y4cSVeA= X-Alimail-AntiSpam:AC=PASS;BC=-1|-1;BR=01201311R131e4;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=maildocker-contentspam011083073210;MF=hsiangkao@linux.alibaba.com;NM=1;PH=DS;RN=10;SR=0;TI=SMTPD_---0X.cto9G_1774319100; Received: from 30.221.131.232(mailfrom:hsiangkao@linux.alibaba.com fp:SMTPD_---0X.cto9G_1774319100 cluster:ay36) by smtp.aliyun-inc.com; Tue, 24 Mar 2026 10:25:00 +0800 Message-ID: Date: Tue, 24 Mar 2026 10:24:59 +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 v2 6.1] erofs: Fix the slab-out-of-bounds in drop_buffers() To: Denis Arefev , stable@vger.kernel.org, Greg Kroah-Hartman Cc: Gao Xiang , Chao Yu , Jeffle Xu , linux-erofs@lists.ozlabs.org, linux-kernel@vger.kernel.org, lvc-project@linuxtesting.org, syzbot+5b886a2e03529dbcef81@syzkaller.appspotmail.com References: <20260323135936.15070-1-arefev@swemel.ru> From: Gao Xiang In-Reply-To: <20260323135936.15070-1-arefev@swemel.ru> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 2026/3/23 21:59, Denis Arefev wrote: > commit ce529cc25b184e93397b94a8a322128fc0095cbb upstream. > > This was accidentally fixed in commit ce529cc25b18, but it's not possible > to accept all the changes, due to the lack of large folios support for > Linux 6.1 kernels, so this is only the actual bug fix that's needed. > > [Background] > > Syzbot reported that a KASAN slab-out-of-bounds bug was discovered in > the drop_buffers() function [1]. > > The root cause is that erofs_raw_access_aops does not define .release_folio > and .invalidate_folio. When using iomap-based operations, folio->private > may contain iomap-specific data rather than buffer_heads. Without special > handlers, the kernel may fall back to generic functions (such as > drop_buffers), which incorrectly treat folio->private as a list of > buffer_head structures, leading to incorrect memory interpretation and > out-of-bounds access. > > Fix this by explicitly setting .release_folio and .invalidate_folio to the > values of iomap_release_folio and iomap_invalidate_folio, respectively. > > [1] https://syzkaller.appspot.com/x/report.txt?x=12e5a142580000 > > Fixes: 7479c505b4ab ("fs: Convert iomap_readpage to iomap_read_folio") > Reported-by: syzbot+5b886a2e03529dbcef81@syzkaller.appspotmail.com > Closes: https://syzkaller.appspot.com/bug?id=c6aeabd0c4ad2466f63a274faf2a123103f8fbf7 > Signed-off-by: Denis Arefev Reviewed-by: Gao Xiang Thanks, Gao Xiang