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: <20c3ba51-fbf1-4de2-b88f-5edf817a24d6@suse.com>
Date: Mon, 12 Jan 2026 07:12:59 +1030
From: Qu Wenruo <wqu@...e.com>
To: jollycar <jollycar@...ton.me>
Cc: "regressions@...ts.linux.dev" <regressions@...ts.linux.dev>,
 "linux-btrfs@...r.kernel.org" <linux-btrfs@...r.kernel.org>,
 "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [REGRESSION] VirtualBox VM crashes (BSOD) during Windows
 installation on btrfs with kernels 6.18+ (works on 6.12 LTS)



在 2026/1/11 21:39, jollycar 写道:
> Storage configuration details:
> 
> Storage format: VDI (VirtualBox Disk Image)
> Storage location: /data/virtual-os/ (btrfs subvolume with COW disabled, verified with lsattr)

OK, this means it's not related to the direct IO changes in newer kernels.

When COW is disabled, data checksum is also disables, thus direct IO is 
still doing the true zero-copy behavior.

This ruled out the btrfs direct io change, but this means I have no clue 
what is going wrong at all now.

> Controller: IntelAhci (SATA)
> Default configuration: hostiocache on, mtype normal
> 
> Cache and media type testing on kernel 6.18.3:
> - Default (hostiocache on, mtype normal): BSOD within 1 minute during installation
> - mtype writethrough: Gets much further, BSOD occurs on first VM reboot
> - hostiocache off (mtype normal): Gets much further, BSOD occurs on first VM reboot
> 
> None of the configurations provide a working solution - they only delay the crash.
> 
> On kernel 6.12.63 with default settings (hostiocache on, mtype normal), Windows installation completes successfully without any crashes.
> 
> I have not yet tested with qemu/libvirt. Should I proceed with that test?

Yes please. Libvirt/qemu is a more common solution among developers.
If you can reproduce it using libvirt/qemu, more btrfs developers can 
try to reproduce it and look into it.

And if not, the cause may shift towards vbox other than btrfs.

Thanks,
Qu

> 
> 
> On Sunday, January 11th, 2026 at 10:15 AM, Qu Wenruo <wqu@...e.com> wrote:
> 
>>
>>
>>
>>
>> 在 2026/1/11 20:33, jollycar 写道:
>>
>>> #regzbot introduced: v6.12..v6.18
>>>
>>> [1.] One line summary of the problem:
>>> VirtualBox VM crashes with BSOD during Windows installation on kernels 6.18+ (works fine on 6.12 LTS)
>>>
>>> [2.] Full description of the problem:
>>> Windows 10 and Windows 11 installation inside VirtualBox consistently crashes with BSOD within 1-3 minutes on Linux kernels 6.18.3 and 6.19-rc3. The same VirtualBox configuration and VM image work perfectly on kernel 6.12 LTS. The BSOD errors vary each time (most recent: 0x80070470 - "file may be corrupt or missing"). The host system remains completely stable with no logged errors.
>>>
>>> [3] Kernel & Hardware:
>>> - Kernel versions tested:
>>> * Working: 6.12.63-1
>>> * Broken: 6.18.3-2, 6.19.0-rc3-1
>>> - Distribution: Manjaro Linux
>>> - Architecture: x86_64
>>> - VirtualBox: 7.2.4 r170995 (vboxdrv vermagic: 6.18.3-2-MANJARO SMP preempt mod_unload)
>>>
>>> [4.] Filesystem and storage:
>>> - Root filesystem: btrfs on LUKS encryption
>>> - Mount options: zstd compression level 3, SSD optimizations, async discard, free space tree
>>> - VM storage: separate btrfs subvolume
>>
>>
>> What's the storage file configuration? Like what's the cache mode setting?
>> I don't know VBox at all, but there may be something similar to
>> libvirt's cache mode (none/unsafe/writethrough etc).
>>
>> More importantly, will tweaking the cache mode change fix the broken
>> kernels?
>> If so it may point to direct IO related behavior changes.
>>
>>
>> And what's the storage file format? QCOW2? RAW? Or whatever format
>> provided by Vbox?
>>
>>
>> And one final question, have you tried qemu (or libvirt + qemu) and can
>> it still be reproduced with qemu?
>> As I'm wondering if the direct IO related change will even affects qemu
>>
>> Thanks,
>> Qu
>>
>>> - btrfs device stats: all zeros (no errors)
>>>
>>> [5.] Reproduction:
>>> - Boot kernel 6.18.3-2 or 6.19.0-rc3
>>> - Start VirtualBox 7.2.4 r170995
>>> - Create new Windows 10 or Windows 11 VM
>>> - Begin OS installation
>>> - BSOD occurs within 1-3 minutes with varying errors (latest: 0x80070470)
>>> - Issue is 100% reproducible on 6.18+, never occurs on 6.12
>>>
>>> Additional context:
>>> - Host system remains completely stable during VM crashes
>>> - No btrfs errors in dmesg or device stats (all zero)
>>> - Issue persists across multiple 6.18/6.19 releases over one month
>>> - VirtualBox 7.2.4 modules load successfully on all kernel versions
>>>
>>> Regards,
>>> Jollycar


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ