VirtualBox

Ticket #10173 (new defect)

Opened 2 years ago

Last modified 22 months ago

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

Reported by: Steltek Owned by:
Priority: major Component: other
Version: VirtualBox 4.1.8 Keywords: iscsi segmentation fault
Cc: Guest type: Linux
Host type: Linux

Description (last modified by aeichner) (diff)

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

Attachments

trace.pcap Download (41.0 KB) - added by Steltek 2 years ago.
Network trace with iSCSI users 'test', 'testServer1' and 'testserver1' and password 'testtesttest' for all.

Change History

comment:1 Changed 2 years ago by Steltek

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

comment:2 Changed 2 years ago by 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.)

comment:3 Changed 2 years ago by aeichner

  • Description modified (diff)

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.

comment:4 Changed 2 years ago by aeichner

  • Summary changed from Mistake with iSCSI authentication causes Segmentation Fault to Mistake with iSCSI authentication causes Segmentation Fault => fixed in svn/next maintenance release

comment:5 Changed 2 years ago by 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.

Changed 2 years ago by Steltek

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

comment:6 Changed 2 years ago by Technologov

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

comment:7 Changed 2 years ago by 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.)

comment:8 Changed 22 months ago by 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).

Note: See TracTickets for help on using tickets.

www.oracle.com
ContactPrivacy policyTerms of Use