linux-kernel - Re: BUG: unable to handle kernel paging request in z_erofs_decompress

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <947527a5-f345-b7c8-6938-9a8d2863fbac@linaro.org>
Date:   Tue, 20 Dec 2022 17:42:21 +0200
From:   Tudor Ambarus <tudor.ambarus@...aro.org>
To:     Gao Xiang <hsiangkao@...ux.alibaba.com>
Cc:     linux-erofs@...ts.ozlabs.org, xiang@...nel.org, chao@...nel.org,
        huyue2@...lpad.com, jefflexu@...ux.alibaba.com,
        joneslee@...gle.com, linux-kernel@...r.kernel.org
Subject: Re: BUG: unable to handle kernel paging request in
 z_erofs_decompress_queue

Hi, Gao,

On 15.12.2022 16:24, Gao Xiang wrote:
> Hi Tudor,
> 
> On Thu, Dec 15, 2022 at 02:58:10PM +0200, Tudor Ambarus wrote:
>> Hi, Gao, Chao, Yue, Jeffle, all,
>>
>> Syzbot reported a bug at [1] that is reproducible in upstream kernel
>> since
>>    commit 47e4937a4a7c ("erofs: move erofs out of staging")
>>
>> and up to (inclusively)
>>    commit 2bfab9c0edac ("erofs: record the longest decompressed size in this
>> round")
>>
>> The first commit that makes this bug go away is:
>>    commit 267f2492c8f7 ("erofs: introduce multi-reference pclusters
>> (fully-referenced)")
>> Although, this commit looks like new support and not like an explicit
>> bug fix.
>>
>> I'd like to fix the lts kernels. I'm happy to try any suggestions or do
>> some tests. Please let me know if the bug rings a bell.
> 
> Thanks for your report.  I will try to seek time to look at this this
> weekend.  But just from your description, I guess that there could be
> something wrong on several compressed extents pointing to the same
> blocks (i.e. the same pcluster).  But prior to commit 267f2492c8f7, such
> image is always considered as corrupted images.
> 
> Anyway, I will look into that and see if there could be alternative ways
> to fix this rather than backport the whole multi-reference pcluster
> feature.  Yet I think no need to worry since such image is pretty
> crafted and should be used as normal images.

I guess to backport the multi-reference pcluster feature is not an
option for stable - just fixes are accepted. If you think it is worth
fixing the problem without adding new support, I can dive into it.
Let me know what you think.

Thanks,
ta

> 
> Thanks,
> Gao Xiang
> 
>>
>> Thanks,
>> ta
>>
>> [1]
>> https://syzkaller.appspot.com/bug?id=a9b56d324d0de9233ad80633826fac76836d792a