Bug 255386 - emulators/virtualbox-ose-additions: FreeBSD 13 virtualbox guest reboot when trying to acces the mounted shared folder
Summary: emulators/virtualbox-ose-additions: FreeBSD 13 virtualbox guest reboot when t...
Status: Open
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: amd64 Any
: --- Affects Some People
Assignee: Virtualbox Team (Nobody)
URL:
Keywords: crash
Depends on:
Blocks:
 
Reported: 2021-04-25 06:43 UTC by philippe972
Modified: 2023-08-19 08:18 UTC (History)
6 users (show)

See Also:


Attachments
dumped core (114.46 KB, text/plain)
2021-05-12 16:20 UTC, philippe972
no flags Details
proposed patch to patch uninitialized pointer to node (398 bytes, patch)
2021-09-10 22:17 UTC, martin
grahamperrin: maintainer-approval? (vbox)
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description philippe972 2021-04-25 06:43:05 UTC
I run Freebsd 13-RELEASE as virtualbox guest with virtualbox-ose-additions 6.1.20 from package
After a mount_vboxvfs with no issue, the virtual machine reboot each time i try to acces the shared folder
Comment 1 Li-Wen Hsu freebsd_committer freebsd_triage 2021-04-25 15:20:51 UTC
Do you have vboxguest.ko loaded and are you sure you're using virtualbox-ose-additions 6.1.20?

I believe this issue has been resolved with this commit and included with 6.1.18_1:

https://cgit.freebsd.org/ports/commit/?id=8a311de0cb804d8b135413884b4fb336d287ad5a

I just tried with 13.0-RELEASE vm from https://app.vagrantup.com/bento/boxes/freebsd-13.0 and upgraded virtualbox-ose-additions-nox11 to 6.1.20, the shared folder works fine.
Comment 2 philippe972 2021-04-25 18:11:28 UTC
(In reply to Li-Wen Hsu from comment #1)
vboxguest.ko is loaded and virtualbox-ose-additions 6.1.20 from ports
Comment 3 mauro 2021-05-07 10:48:34 UTC
Hi, just add -by my usage cases- that virtualbox-ose-addition recent update has solved this issue in the Windows10 hosted  Freebsd 13 virtual machine, but it still remains same (machine reboots as attempting to open the shared folder) on the Ubuntu hosted VirtualBox, same version in both hosts, 6.1.19
Comment 4 Guido Falsi freebsd_committer freebsd_triage 2021-05-07 15:42:04 UTC
(In reply to mauro from comment #3)

Can you produce a core dump and/or a backtrace of the crash?

You should configure a dump device in FreeBSD.

Without such information it's really hard to guess what is going on.
Comment 5 mauro 2021-05-08 10:48:27 UTC
Good morning Guido, thanks for your reply.
I'd like to proceed as per your suggestion, the fact is that I'm taking knowledge of Freebsd since less than one month, And don't know anything on how to produce what requested to investigate the issue.
If you think it is good to instruct me step by step for this, I'm ready from my side.

Furthermore I can tell that meantime I also installed a NomadBSD 1.4 system (based on FreeBSD 12.2 kernel) as VirtualBox machine, and it does not encounter any problem in accessing the setted shared folder both in Windows host and in Ubuntu as well.  The Guest Additions installation was already included in the system distribution.
Regards
Comment 6 mauro 2021-05-08 11:01:49 UTC
Good morning Guido, thanks for your reply.
I'd like to proceed as per your suggestion, the fact is that I'm taking knowledge of Freebsd since less than one month, And don't know anything on how to produce what requested to investigate the issue.
If you think it is good to instruct me step by step for this, I'm ready from my side.

Furthermore I can tell that meantime I also installed a NomadBSD 1.4 system (based on FreeBSD 12.2 kernel) as VirtualBox machine, and it does not encounter any problem in accessing the setted shared folder both in Windows host and in Ubuntu as well.  The Guest Additions installation version is 5.2.44_3, and was already included in the system distribution.
Regards
Comment 7 philippe972 2021-05-08 16:14:41 UTC
(In reply to Guido Falsi from comment #4)

Please, Could you explain how to produce a core dump or a backtrace of the crash?

Thanks
Comment 8 Guido Falsi freebsd_committer freebsd_triage 2021-05-08 19:36:43 UTC
To have the kernel save a core dump you need the machine (virtual or physical) to have more swap than ram and configure it to perform the dump with dumpdev="AUTO" in /etc/rc.conf.

A machine without any swap (which is a relatively common setup for virtual machines) has no way to save a kernel core dump.

But to get actually useful data you should be running a debugging kernel.

I think, especially since we're talking about virtual machines, it would be easier for you to install a VM with a snapshot of 14-CURRENT, that comes with debugging kernel by default and see if the problem happens there, you should then be dropped in the debugger an automatically get a backtrace that could help investigating the issue. Use the "bt" debugger command to print it again (the debugger should do that automatically)

Having a backtrace is no warranty of a resolution but would at least give an idea to what part of the kernel to start looking at.

You should also configure enough swap so you can save a core dump that can be analyzed later. To get that at the debugger prompt use the "save" command, followed by "reboot".

You can get head snapshots from https://download.freebsd.org/ftp/snapshots/amd64/amd64/ISO-IMAGES/14.0/
Comment 9 mauro 2021-05-09 12:08:06 UTC
(In reply to Guido Falsi from comment #8)
Ok, if it is only me having this issue limited to Ubuntu host system, I give up.
The action described are over my capacity to apply them and hope next GA versions could have fixed this. I can survive meantime, as needing a folder sharing in Ubuntu host, involves a minimum part of my cases.
Thank you again
Comment 10 philippe972 2021-05-10 15:38:40 UTC
I have the same issue than Mauro with ubuntu host
.
I give up too, the action described by Guido is too complicated for me

I wait for next GA versions

Thanks
Comment 11 Guido Falsi freebsd_committer freebsd_triage 2021-05-10 16:25:51 UTC
Unluckily debugging is not something that happens by itself.

Anyway, can you state some more details of your setup so maybe someone else can try to replicate the issue?

Some requires information:

Ubuntu version?

VirtualBox version installed on host (from official ubuntu repo?)

Hardware being used (I guess amd64, called x86_64 in linux)? Can you state your CPU? (while improbable, the problem could also be hardware related)

(can't think of other relevant details but anyone can post requests for new details if needed)
Comment 12 philippe972 2021-05-10 17:36:43 UTC
(In reply to Guido Falsi from comment #11)
Host : Ubuntu 20.04.2 LTS x86_64

Virtualbox version on host : 6.1.22 r144080

cpu info :
dmidecode 3.2
Getting SMBIOS data from sysfs.
SMBIOS 2.8 present.

Handle 0x003D, DMI type 4, 42 bytes
Processor Information
        Socket Designation: SOCKET 0
        Type: Central Processor
        Family: Core i5
        Manufacturer: Intel
        ID: C3 06 03 00 FF FB EB BF
        Signature: Type 0, Family 6, Model 60, Stepping 3
        Flags:
                FPU (Floating-point unit on-chip)
                VME (Virtual mode extension)
                DE (Debugging extension)
                PSE (Page size extension)
                TSC (Time stamp counter)
                MSR (Model specific registers)
                PAE (Physical address extension)
                MCE (Machine check exception)
                CX8 (CMPXCHG8 instruction supported)
                APIC (On-chip APIC hardware supported)
                SEP (Fast system call)
                MTRR (Memory type range registers)
                PGE (Page global enable)
                MCA (Machine check architecture)
                CMOV (Conditional move instruction supported)
                PAT (Page attribute table)
                PSE-36 (36-bit page size extension)
                CLFSH (CLFLUSH instruction supported)
                DS (Debug store)
                ACPI (ACPI supported)
                MMX (MMX technology supported)
                FXSR (FXSAVE and FXSTOR instructions supported)
                SSE (Streaming SIMD extensions)
                SSE2 (Streaming SIMD extensions 2)
                SS (Self-snoop)
                HTT (Multi-threading)
                TM (Thermal monitor supported)
                PBE (Pending break enabled)
        Version: Intel(R) Core(TM) i5-4460 CPU @ 3.20GHz
        Voltage: 1.2 V
        External Clock: 100 MHz
        Max Speed: 3800 MHz
        Current Speed: 3200 MHz
        Status: Populated, Enabled
        Upgrade: Socket BGA1155
        L1 Cache Handle: 0x003F
        L2 Cache Handle: 0x003E
        L3 Cache Handle: 0x0040
        Serial Number: Not Specified
        Asset Tag: Fill By OEM
        Part Number: Fill By OEM
        Core Count: 4
        Core Enabled: 4
        Thread Count: 4
        Characteristics:
                64-bit capable
Comment 13 mauro 2021-05-10 18:44:04 UTC
(In reply to Guido Falsi from comment #11)

yes.

-Ubuntu host system amd64 = 20.04 LTS. 
-Storage memory* = 128 Gb
-RAM = 16 Gb
-swap space = 6 Gb
-CPU = Intel i7 dual core
-Video adapter = dual Intel HD 5500 integrated + AMD Radeon M330 2Gb
-VirtualBox installation = v. 6.1.19, with Extensions Pack, 
-VirtualBox .deb package downloaded from the Virtualbox site page

Virtual Machine config:
-Storage memory** = 256 Gb
-RAM = 8 Gb
-Video Memory = 128 Mb
-cpu cores = 1
-Video adapter = VBoxSVGA  (also works with VBoxVGA)
-USB filter = enabled
-Shared folder = enabled on /home/myuser/  with automount and complete control, also added user permissions for vboxsf with "sudo adduser $USER vboxsf"

Hardware config (HP laptop):
-Storage memory = SSD 1 Tb
-RAM = 16 GB
-CPU = Intel i7 dual core 
-Video adapter = dual Intel HD 5500 integrated + AMD Radeon M330 2Gb
-system booting on SSD disk = Windows 10 20H2
-Bios UEFI + Legacy

Freebsd 13 guest config:
-Storage memory** = 256 Gb
-RAM = 8 Gb
-swap space = 2 Gb
-VBox Guest Additions = latest update of virtualbox-ose-additions  from FreeBSD packages repository


*Ubuntu host system 20.04 LTS is installed in a bootable USB3 pendrive of 128 Gb

**FreeBSD 13 guest system is installed in a USB3 pendrive of 256 Gb which can also be booted from inside a Virtualbox session even hosted in a smaller storage space. Works same both as a physical USB3 bootable volume, and also as virtual machine handled in a VirtualBox session.

A NomadBSD 1.4 system installed in same mode (physical USB3 bootable also handled by a VirtualBox session) does not give this issue when used as virtual machine in VirtualBox Ubuntu hosted. Shared folders are normally accessible in Ubuntu like in Windows. Guest Additions are already included in this release, version 5.2.44_3 (legacy).
Thank you
Comment 14 philippe972 2021-05-12 16:20:49 UTC
Created attachment 224876 [details]
dumped core
Comment 15 philippe972 2021-05-12 16:24:09 UTC
dumped core file if it can help
Comment 16 mauro 2021-05-12 17:44:27 UTC
(In reply to philippe972 from comment #14)

You did it Philippe, useful job from you rather than me :)
Thanks
Comment 17 Guido Falsi freebsd_committer freebsd_triage 2021-05-12 17:51:25 UTC
(In reply to philippe972 from comment #15)

The dump you posted has some useful information.

It indicates the issue happens in the vboxfs_readdir() function. Unluckily there 
are no details about where more exactly and due to what cause.

also this line:

current process		= 866 (gvfs-udisks2-volume)

makes me suspicious.

Are you automounting vbox shared folders from some desktop environment? Not sure the FreeBSD additions shared folder driver supports that.

If you're not already doing it, could you mount the shared folder at boot from fstab, with a line like this:

VMs  /mnt/vbox	vboxvfs	 rw,late,uid=1001,gid=1001	0	0

(VMs being the name of the shared folder you gave in virtualbox, the other fields should be self explanatory)

Nor sure I can help much more.
Comment 18 philippe972 2021-05-14 08:08:20 UTC
(In reply to Guido Falsi from comment #17)
I think I have found the beginning of an explanation :
when sharefolder name is initialy lowercase all works fine with the mount_vboxvfs command

I also tried to rename sharefolder name uppercase to lowercase, the mount_vboxvfs command make the VM reboot

 this is the first result of my research
Comment 19 Guido Falsi freebsd_committer freebsd_triage 2021-05-14 15:26:46 UTC
(In reply to philippe972 from comment #18)

Are you sure the problem is with upper/lower case? While possible it looks strange.

Could it be caused by non ascii characters instead? would make much more sense.
Comment 20 mauro 2021-05-14 17:53:47 UTC
in my personal case, this is the mount command I give (working in Windows host, reboot the machine in Ubuntu host):

doas mount -t vboxvfs mauro /home/mauro/shared/

where mauro is the Virtualbox shared folder choosen in Ubuntu (path home/mauro) but also in Windows (Users/mauro).  And shared is the folder I created inside /home/mauro/ in Freebsd guest to access the shared folder
Comment 21 Graham Perrin freebsd_committer freebsd_triage 2021-09-05 17:34:23 UTC
For the bug to be found in the normal way, please prefix the summary line. Probably: 

emulators/virtualbox-ose-additions

Thanks
Comment 22 martin 2021-09-10 22:17:19 UTC
Created attachment 227816 [details]
proposed patch to patch uninitialized pointer to node
Comment 23 martin 2021-09-10 22:18:39 UTC
For the tests I used the VM-IMAGES, release one (vm1) and snapshot (vm2).

vm1: releng/13.0-n244733-ea31abc261f, additions 6.1.22 r144080
vm2: stable/13-n247062-c4bd6b589c8, additions 6.1.26 r145957 

I saw no problem on Ubuntu 20.10 with 6.1.16-dfsg-6~ubuntu1.20.10.1. Both VMs were crashing under 20.04 with 6.1.26-dfsg-3~ubuntu1.20.04.1.

For my tests I focused on host Ubuntu 20.04, release vm1. I mounted the shared directory coming from host to /shared on guest. Creating dirs, removing them seemed ok. It was always crashing in vboxfs_readdir() on obviously bogus address: 0x15 or something very similar. 

I checked the sources of virtualbox-ose-additions-nox11-6.1.26, the src/VBox/Additions/freebsd/vboxvfs/vboxvfs_vnops.c:1092

1092                 if (strcmp(dirent->sf_entry.d_name, ".") == 0) {
1093                         node = dir;
1094                 } else if (strcmp(dirent->sf_entry.d_name, "..") == 0) {
1095                         node = dir->sf_parent;
1096                         if (node == NULL)
1097                                 node = dir;
1098                 } else {
1099 #if 0
1100                         node = vsfnode_lookup(dir, dirent->sf_entry.d_name, VNON,
1101                             0, &dirent->sf_stat, vsfnode_cur_time_usec(), NULL);
1102                         if (node == NULL)
1103                                 panic("sffs_readdir() lookup failed");
1104 #endif
1105                 }
1106
1107                 if (node)
1108                         dirent->sf_entry.d_fileno = node->sf_ino;
1109                 else
1110                         dirent->sf_entry.d_fileno = 0xdeadbeef;


It seems the vboxfs_node node pointer is being used uninitialized. 

I don't get it how come it works under Ubuntu 20.10 (coincidence ?). But setting the pointer to NULL did the trick:

1012         struct vboxfs_node *node = NULL;

I've never did write any patch for public, I've attached one.
Comment 24 Guido Falsi freebsd_committer freebsd_triage 2021-09-11 17:54:25 UTC
(In reply to martin ilavsky from comment #23)

God catch, the fact that the else block is surrounded by  #if 0 definitely makes it possible to use the node variable undefined.

Your patch would prevent a crash due to referencing a random pointer, but I'm not able to review it for possible further unwanted consequences or crashes down the line.

That 

dirent->sf_entry.d_fileno = 0xdeadbeef;

looks dangerous and I don't know enough aboud the vfs interface to understand that.

The commented code explicitly calls panic if node == NULL.

This worries me a little.

I could not find any information regarding vsfnode_lookup(), so I cannot guess what the commented code is trying to do.

So to sum up, avoiding use of undefined variable is anyway correct, and I'm going to test it and also commit it probably.

BUT the code path defining "dirent->sf_entry.d_fileno = 0xdeadbeef;" looks a little fishy to me and could cause issues later when using the FS. I'd really like to have someone with better knowledge of the file system interface review this, so I don't think the issue should be closed with this patch.
Comment 25 Guido Falsi freebsd_committer freebsd_triage 2021-09-11 18:13:48 UTC
(In reply to martin ilavsky from comment #23)

If you could shed some light on that vsfnode_lookup() function purpose it would be of great help to try to understand what is happening here.
Comment 26 martin 2021-09-11 18:36:46 UTC
(In reply to Guido Falsi from comment #25)
I saw the code for the first time yesterday, I was debugging the dumps somebody mentioned on the forums. I'm trying to get more familiar with the module but there's lots of stuff to understand.

During my tests I found out (with or without my patch) if you run ls in loop long enough (matter of seconds) module reports back out of memory and you can't browse the shared directory at all. Happens on all combinations of host - FreeBSD guest I tried. The only option to make it work again is to unmount the share and unload the module.
Comment 27 commit-hook freebsd_committer freebsd_triage 2021-09-11 20:42:15 UTC
A commit in branch main references this bug:

URL: https://cgit.FreeBSD.org/ports/commit/?id=1b2394551c038558810be8bf396462174db334be

commit 1b2394551c038558810be8bf396462174db334be
Author:     Martin Ilavsky <ilavsky.martin@gmail.com>
AuthorDate: 2021-09-11 20:38:50 +0000
Commit:     Guido Falsi <madpilot@FreeBSD.org>
CommitDate: 2021-09-11 20:38:50 +0000

    emulators/virtualbox-ose-additions: Assign default value to pointer

    In the virtualbox virtual filesystem code we ship as a patch some
    code in an else block is commented out. This produces a code path
    in which a pointer variable is dereferenced in an unassigned state,
    causing random crashes.

    Lacking a better fix, give a default value of NULL to the pointer,
    which at least avoids the random pointer dereference issue.

    PR:             255386

 emulators/virtualbox-ose-additions/Makefile                           | 1 +
 .../files/patch-src_VBox_Additions_freebsd_vboxvfs_vboxvfs__vnops.c   | 4 ++--
 2 files changed, 3 insertions(+), 2 deletions(-)
Comment 28 Guido Falsi freebsd_committer freebsd_triage 2021-09-11 20:44:33 UTC
@martin

I committed your patch, since it corrects an actual issue (uninitialized random pointer dereference), but as I said I'm not sure this fixes the whole issue, and more problems are lurking in the code.
Comment 29 martin 2021-09-11 20:53:31 UTC
(In reply to Guido Falsi from comment #28)
Thanks. I agree. I was not able to find any reference to vsfnode_lookup(), neither in FreeBSD 12/13 src nor in the VirtualBox code (5.x and 6.x).

But it seems the code was borrowed from the Solaris additions. There are more comments in the code too. Slowly trying to understand it.
Comment 30 commit-hook freebsd_committer freebsd_triage 2021-09-12 12:14:54 UTC
A commit in branch 2021Q3 references this bug:

URL: https://cgit.FreeBSD.org/ports/commit/?id=d557edd568b5e127b6f8eefad4ba071c3aa123f9

commit d557edd568b5e127b6f8eefad4ba071c3aa123f9
Author:     Martin Ilavsky <ilavsky.martin@gmail.com>
AuthorDate: 2021-09-11 20:38:50 +0000
Commit:     Guido Falsi <madpilot@FreeBSD.org>
CommitDate: 2021-09-12 12:11:53 +0000

    emulators/virtualbox-ose-additions: Assign default value to pointer

    In the virtualbox virtual filesystem code we ship as a patch some
    code in an else block is commented out. This produces a code path
    in which a pointer variable is dereferenced in an unassigned state,
    causing random crashes.

    Lacking a better fix, give a default value of NULL to the pointer,
    which at least avoids the random pointer dereference issue.

    PR:             255386
    (cherry picked from commit 1b2394551c038558810be8bf396462174db334be)

 emulators/virtualbox-ose-additions/Makefile                           | 1 +
 .../files/patch-src_VBox_Additions_freebsd_vboxvfs_vboxvfs__vnops.c   | 4 ++--
 2 files changed, 3 insertions(+), 2 deletions(-)
Comment 31 commit-hook freebsd_committer freebsd_triage 2021-10-17 09:33:39 UTC
A commit in branch main references this bug:

URL: https://cgit.FreeBSD.org/ports/commit/?id=c43e12a46f329c2ff336f06c61a6eb6be0ac9108

commit c43e12a46f329c2ff336f06c61a6eb6be0ac9108
Author:     Guido Falsi <madpilot@FreeBSD.org>
AuthorDate: 2021-10-17 09:29:56 +0000
Commit:     Guido Falsi <madpilot@FreeBSD.org>
CommitDate: 2021-10-17 09:32:33 +0000

    emulators/virtualbox-ose-additions-legacy: Import improvements from non legacy port

    Import changes from commit 1b2394551c0385 to legacy port:

    In the virtualbox virtual filesystem code we ship as a patch some
    code in an else block is commented out. This produces a code path
    in which a pointer variable is dereferenced in an unassigned state,
    causing random crashes.

    Lacking a better fix, give a default value of NULL to the pointer,
    which at least avoids the random pointer dereference issue.

    PR:             255386

    Alsso import fix for building on recent head from cec55f41e10f13:

    Fix build after head commit b4a58fbf640409a1 (vfs: remove cn_thread)

    MFH:            2021Q4

 emulators/virtualbox-ose-legacy/Makefile           |  2 +-
 ...VBox_Additions_freebsd_vboxvfs_vboxvfs__vnops.c | 25 +++++++++-------------
 2 files changed, 11 insertions(+), 16 deletions(-)
Comment 32 commit-hook freebsd_committer freebsd_triage 2021-10-17 09:34:41 UTC
A commit in branch 2021Q4 references this bug:

URL: https://cgit.FreeBSD.org/ports/commit/?id=705ba6bb024b625f3914f56cdc9f92334b0c7ff7

commit 705ba6bb024b625f3914f56cdc9f92334b0c7ff7
Author:     Guido Falsi <madpilot@FreeBSD.org>
AuthorDate: 2021-10-17 09:29:56 +0000
Commit:     Guido Falsi <madpilot@FreeBSD.org>
CommitDate: 2021-10-17 09:33:39 +0000

    emulators/virtualbox-ose-additions-legacy: Import improvements from non legacy port

    Import changes from commit 1b2394551c0385 to legacy port:

    In the virtualbox virtual filesystem code we ship as a patch some
    code in an else block is commented out. This produces a code path
    in which a pointer variable is dereferenced in an unassigned state,
    causing random crashes.

    Lacking a better fix, give a default value of NULL to the pointer,
    which at least avoids the random pointer dereference issue.

    PR:             255386

    Alsso import fix for building on recent head from cec55f41e10f13:

    Fix build after head commit b4a58fbf640409a1 (vfs: remove cn_thread)

    MFH:            2021Q4
    (cherry picked from commit c43e12a46f329c2ff336f06c61a6eb6be0ac9108)

 emulators/virtualbox-ose-legacy/Makefile           |  2 +-
 ...VBox_Additions_freebsd_vboxvfs_vboxvfs__vnops.c | 25 +++++++++-------------
 2 files changed, 11 insertions(+), 16 deletions(-)
Comment 33 Graham Perrin freebsd_committer freebsd_triage 2023-08-19 08:18:06 UTC
Sorry, ignore my flag for feedback on the patch. 

Now I see (comment #28): 

> I committed your patch, …