Re: [Iscsitarget-devel] iscsitarget hangs on invalid packet received

[Steffen P. <swp...@am...>]

Hi Marek,

I have been reading the SCSI-3 command set spec and for the Write(10) command in packet number 6 of your dump it appears that the Transfer Length is set to zero. According to the spec it should be interpreted as 256 (this assumes that I am reading correctly).

I found some interesting code in the set_offset_and_length() function of iscsi.c kernel component where it shows for WRITE_6 a default for len of 256 if the length is not set - i.e. zero. The same code does not appear for WRITE_10 or WRITE_16:

        switch (cmd[0]) {
        case READ_6:
        case WRITE_6:
                *off = ((cmd[1] & 0x1f) << 16) + (cmd[2] << 8) + cmd[3];
                *len = cmd[4];
                if (!*len)
                        *len = 256;   <<<<<<<<<<<<<<<<<<<<<
                break;
        case READ_10:
        case WRITE_10:
        case WRITE_VERIFY:
                *off = (u32)cmd[2] << 24 | (u32)cmd[3] << 16 |
                        (u32)cmd[4] << 8 | (u32)cmd[5];
                *len = (cmd[7] << 8) + cmd[8];  <<<<<<<<<<<<<<<<<<<
                break;
        case READ_16:
        case WRITE_16:
        case WRITE_SAME_16:
                *off = (u64)cmd[2] << 56 | (u64)cmd[3] << 48 |
                        (u64)cmd[4] << 40 | (u64)cmd[5] << 32 |
                        (u64)cmd[6] << 24 | (u64)cmd[7] << 16 |
                        (u64)cmd[8] << 8 | (u64)cmd[9];
                *len = (u32)cmd[10] << 24 | (u32)cmd[11] << 16 |
                        (u32)cmd[12] << 8 | (u32)cmd[13];
                break;

So, from the code and packet sample, it looks like the len may end up being zero.  For me to debug this further, I saw in your trace the initiator:

KeyValue: InitiatorName=iqn.2000-04.com.qlogic:qle4060c.ls41145a77115.1

We have one of those cards also deployed - would it be possible for you to determine the firmware version/bios version of the card, I could try to apply that version to my spare HBA and see if the problem is reproducible. Also, what exact writes were you doing to produce the problem.

I have done a tcpdump on our side and done some simple write tests and checked the Transfer Length - and they appear to have values set.

Steffen

_______________________________________________________________________________________________
Steffen Plotner                            Amherst College            Tel (413) 542-2348
Systems/Network Administrator/Programmer   PO BOX 5000                Fax (413) 542-2626
Systems & Networking                       Amherst, MA 01002-5000     swp...@am...

From: Marek Mrva [mailto:mr...@es...]
Sent: Monday, March 24, 2014 8:39 AM
To: isc...@li...
Subject: [Iscsitarget-devel] iscsitarget hangs on invalid packet received

Hello,

I've stumbled upon what I believe is a bug in the iscsitarget implementation.

The attached .pcap file is a log of network communication between a QLogic iSCSI card and a Gentoo server running ietd daemon.
The Linux box has version 1.4.20.2_p20130821 of the iscsitarget package installed, as available from the Gentoo portage repository.

The hardware card (under yet unknown circumstances, possibly because of another bug) generates a malformed packet (#6 in the dump).
This packet has the transfer length field set to 0, which I believe is an invalid value for this packet type.

After it is received, the ietd daemon gets locked-out, unable to complete further operations.
For example, reading the contents of /proc/net/iet/* files will be delayed indefinitely.


Any help with this bug would be greatly appreciated. If it is of any help, I can attempt to write a patch for this bug myself and submit it to you afterwards.



Best regards,
Marek Mrva