Created attachment 306631 [details] virtualbox error log After commits: 9c573cd31343 randomize_kstack: Improve entropy diffusion ef40d28f17bd randomize_kstack: Remove non-functional per-arch entropy filtering The first bad commit will cause the crash of virtualbox 6.1.50. v6.11-rc1 will reproduce this issue too, after revert the 2 commits, virtualbox 6.1.50 works well. The initial bug was reported in: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2073267
The bug report on launchpad.net mentions the use of third-party kernel modules, which is something we can't debug or control. The most logical explanation here would be that there is a bug in the virtualbox modules that uses a lot of stack space. Since the 9c573cd31343 patch, the randomization adds up to 1024 bytes of stack space, where it would have used only 256 bytes before. There are 16KB of total stack space available per thread, so if the patch caused an overflow, it would have already been in the last kilobyte before it. If CONFIG_VMAP_STACK is enabled in the kernel, the kernel log messages should contain a backtrace for the kernel function that ran into the overflow, which likely shows the culprit.
Created attachment 306636 [details] upstream kernel v6.11-rc1 with virtualbox6.1.50 crash dmesg Attached the dmesg after the issue is reproduced. VMAP_STACK is enabled. Thanks for your kindly help.
I don't see any report about stack overflow, but there are some other very alarming warnings about this module. They appear to be the same that were reported in https://www.virtualbox.org/ticket/21877.
Hi Bergmann, These UBSAN is not the log of virtualbox crash. When virtualbox6 works, the UBSAN is there too.
UBSAN warnings indicate undefined behavior in the kernel module, so as long as those are there, I don't think it's investigating further. Apparently they have been fixed in newer versions of the virtualbox modules, so you could either upgrade virtualbox to a new enough version or try to backport the bugfixes and then see if the crash still happens.