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] [day] [month] [year] [list]
Message-ID: <b3cf4210-273f-4967-b544-39c47cb0ec96@gmx.com>
Date: Fri, 28 Mar 2025 07:34:42 +1030
From: Qu Wenruo <quwenruo.btrfs@....com>
To: dsterba@...e.cz,
 syzbot <syzbot+34122898a11ab689518a@...kaller.appspotmail.com>
Cc: clm@...com, dsterba@...e.com, josef@...icpanda.com,
 linux-btrfs@...r.kernel.org, linux-kernel@...r.kernel.org,
 syzkaller-bugs@...glegroups.com
Subject: Re: [syzbot] [btrfs?] kernel BUG in write_all_supers



在 2025/3/28 02:55, David Sterba 写道:
> On Thu, Mar 27, 2025 at 09:15:26AM -0700, syzbot wrote:
>> Hello,
>>
>> syzbot found the following issue on:
>>
>> HEAD commit:    f6e0150b2003 Merge tag 'mtd/for-6.15' of git://git.kernel...
>> git tree:       upstream
>> console output: https://syzkaller.appspot.com/x/log.txt?x=1405d804580000
>> kernel config:  https://syzkaller.appspot.com/x/.config?x=46a07195688b794b
>> dashboard link: https://syzkaller.appspot.com/bug?extid=34122898a11ab689518a
>> compiler:       Debian clang version 15.0.6, GNU ld (GNU Binutils for Debian) 2.40
>> syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=10d7abb0580000
>> C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=15d76198580000
>>
>> Downloadable assets:
>> disk image (non-bootable): https://storage.googleapis.com/syzbot-assets/7feb34a89c2a/non_bootable_disk-f6e0150b.raw.xz
>> vmlinux: https://storage.googleapis.com/syzbot-assets/7ade4c34c9b1/vmlinux-f6e0150b.xz
>> kernel image: https://storage.googleapis.com/syzbot-assets/1fe37b97ec9d/bzImage-f6e0150b.xz
>> mounted in repro: https://storage.googleapis.com/syzbot-assets/1f4c759fe772/mount_0.gz
>>    fsck result: OK (log: https://syzkaller.appspot.com/x/fsck.log?x=1757abb0580000)
>>
>> IMPORTANT: if you fix the issue, please add the following tag to the commit:
>> Reported-by: syzbot+34122898a11ab689518a@...kaller.appspotmail.com
>>
>> BTRFS info (device loop0): using sha256 (sha256-avx2) checksum algorithm
>> BTRFS info (device loop0): using free-space-tree
>> assertion failed: folio_order(folio) == 0, in fs/btrfs/disk-io.c:3858
>
> This is
>
> ASSERT(folio_order(folio) == 0);
>
> and the folio is from device->bdev->bd_mapping.
>

And the bdev folios are out of our control, so it's possible the bdev
mapping is utilizing larger folios.

I'll give it a check on the involved function and if everything else
supports large folios, just remove that ASSERT() line.

Thanks,
Qu

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ