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: <LCM3zm3y1s51pkWBZg6NU-4R6f89SVYSAxtNqq0gM5IlDFZfFjwSqvl-8yAvYcl7VizHjXIENm1vf6b7z2e25YQce7IQCr3Ms-w6vKkOKfY=@proton.me>
Date: Sun, 11 Jan 2026 11:09:59 +0000
From: jollycar <jollycar@...ton.me>
To: Qu Wenruo <wqu@...e.com>
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)

Storage configuration details:

Storage format: VDI (VirtualBox Disk Image)
Storage location: /data/virtual-os/ (btrfs subvolume with COW disabled, verified with lsattr)
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?


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