Mistake with iSCSI authentication causes Segmentation Fault => fixed in svn/next maintenance release

[Steltek]

While toying around with iSCSI support recently, I noticed that VirtualBox crashes very quickly at the slightest problem with the SCSI target data (like wrong authentication credentials).

The UI displays an error stating:

Failed to determine the accessibility state of the medium .

Callee RC: NS_ERROR_CALL_FAILED (0x800706BE)

The console where the VirtualBox command was run shows 'Segmentation Fault', the kernel log outputs: [ 6613.591346] VBoxSVC[17042]: segfault at b677b008 ip b73f6626 sp b67783fc error 4 in libc-2.13.so[b737d000+153000] [ 6621.900797] VirtualBox[16970]: segfault at 9d12af8 ip 09d12af8 sp bff4829c error 15

After this crash, it is impossible tostart VirtualBox again until one manually removes all references to the iSCSI volume from the VM's XML config file. (VirtualBox will keep crashing the same way until this is done.)

In addition to that, VirtualBox loses the state of running VMs after this crash (all VMs are shown as 'Powered Off' even though some are running). The only way around this seems to be to shut down all VMs and all VirtualBox related processes, and start everything again.

Host: Debian GNU/Linux wheezy/testing Kernel: Linux server 3.1.0-1-686-pae #1 SMP Tue Jan 10 05:42:54 UTC 2012 i686 GNU/Linux

[Steltek]

Update: Even specifying correct credentials causes the crash. Specifying an invalid target ID seems to be OK (no crash there).

[Steltek]

Update2: When not using CHAP authentication, everything seems to work OK. Rechecking the authentication I noticed that even when giving the correct credentials, the iSCSI server refuses them (as if VirtualBox did not submit them correctly):

Feb 20 00:38:00 kernel: [5976226.290100] rx_data returned 0, expecting 48.
Feb 20 00:38:00 kernel: [5976226.294757] iSCSI - Login negotiation failed from [x.x.x.x]

The username is in this format: MyUsername2
The password is in this format: Simplepasswor

Could there be a problem with the length of these? (The storage system accepts and uses similar username/passwords when used with Debian's open-iscsi initiator, so the problem appears to be with VirtualBox.)

[aeichner]

Sorry that it took so long to reply. I confirmed the crash when using wrong credentials, the fix will be in the next maintenance release, thanks for the report. However I can't reproduce the problem you have when using correct credentials, everything works as epxected. I'm using a 3.2.6 kernel instead of 3.1.0 though, could be a bug in the target but it would be great if you could attach a packet trace too be sure it is not a bug in VirtualBox.

[Steltek]

My turn to be late. ;) I've done some more testing and narrowed down the authentication problem with correct credentials to an upper case letter in the username. I'm attaching the network trace of my tests.

All tests use the password 'testtesttest' and go toward the iSCSI Target iqn.2000-01.com.synology:RackStation.name.

The first test users the username 'test' and succeeded. I then renamed the user on the target, causing VirtualBox to fail (should've removed the disk there first but forgot). The second username was 'testServer1', and when adding it to VirtualBox, it immediately crashed and I had to manually remove it from the config files again. The third test username was 'testserver1' (all lower case), and that one worked again.

As mentioned before, I am using the same username format within Debian directly and without any problem (using open-iscsi as initiator there), so the target appears to be fine with it. Only VirtualBox fails to authenticate against these targets. (Could there be code that lower-cases the username somewhere?)

I also did a fourth test (not traced) with the credentials 'testserver1/testtestTest' (upper case in the PW) and that one worked without any problems, so the problem only appears when there is an upper case letter in the username.

[Steltek]

Network trace with iSCSI users 'test', 'testServer1' and 'testserver1' and password 'testtesttest' for all.

[Technologov]

Maybe it makes sense to label this bug as fixed...

[Steltek]

Actually I just upgraded to 4.1.12 and there seems to be a regression there as it just crashed again. (It didn't crash in 4.1.10 as far as I could see.)

[gatos]

Any news on this? It still crashes with v4.1.18 using OSX as host. It also crashed with 4.1.10 (I upgraded to 4.1.18 hoping there would be a solution).

[aeichner]

Please reopen if still relevant with a recent VirtualBox release.