Flush issue with overwritten FID

Flush issue with overwritten FID

[Federico Sauter]

[-- Attachment #1: Type: text/plain, Size: 2628 bytes --]

Greetings,


I am using a Linux device with kernel 3.10.40. The Windows host is using 
XP PRO (32-bit,) but the problem has laso been observed with Windows 7 
64-bit.

When I directly connect the Linux device to the Windows host, a very 
strange problem arises. First of all: by "directly connect" I mean 
connecting the network cable from the device's NIC directly to the 
host's NIC, without any switch in between.

The device then mounts two shares on the host: a RO share, as well as a 
RW share.

The device opens a file (integrity-check-idx.tmp) for writing on the RW 
share. Then (without closing it) it scans the contents of the RO share. 
Afterwards, it writes some result on that file and flushes it before 
closing it. Straightforward enough.

In the described case where the NICs are directly connected *and* that 
the Windows host finishes booting before the Linux device does, 
something strange happens. The file opened for writing is opened on FID 
0x4002, then, when opening another file on the RO share, the same FID 
seems to be reused. That file is closed and FID 0x4002 is then invalid. 
In the end, when FID 0x4002 is flushed, an error is returned.

Attached you will find an abridged version of the Wireshark capture. 
Here is the summary:

SMB_COM_NT_CREATE_ANDX integrity-check-idx.tmp on FID 0x4002
SMB_COM_READ_ANDX  FID 0x4002
(...browse share...)
SMB_COM_NT_CREATE_ANDX append.exe on FID 0x4002
SMB_COM_READ_ANDX  FID 0x4002
SMB_COM_CLOSE  FID 0x4002
(...)
SMB_COM_FLUSH  FID 0x4002
Response: NT Status: STATUS_INVALID_HANDLE (0xc0000008)

In the case where there is a switch between both NICs, this problem does 
not happen. In that case, FID 0x4002 is used only once for the file 
opened for writing (which was created first) and then other FIDs are 
used for each file that is opened afterwards. Thus, all operations 
succeed (which is the behavior that I would expect.)

Do you have any idea on how to solve this?

I am taking a deeper look at the kernel code, but so far it seems to me 
like this was a Windows problem and not a problem in our implementation, 
given that the FID is assigned by the Windows host. Could you please 
confirm that this is correct so as to provide a workaround?

Thank you in advance for your kind support!


Federico Sauter
Senior Firmware Programmer
-- 
Innominate Security Technologies AG
Rudower Chaussee 13 | 12489 Berlin | Germany
tel: +49 30 921028-210 | fax: +49 30 921028-020
www.innominate.com | www.twitter.com/mGuardcom

Register Court: AG Charlottenburg, HR B 81603
Management Board: Dirk Seewald | Chairman of the Supervisory Board: 
Christoph Leifer

[-- Attachment #2: bug_14517.cap --]
[-- Type: application/vnd.tcpdump.pcap, Size: 4176 bytes --]

Re: Flush issue with overwritten FID

[Federico Sauter]

Hello,


I am using two shares. In order to connect to each share I use a 
different user, but it is the same Windows host. In the abovementioned 
scenario something strange happens while mounting the shares, namely 
that the session setup commands both return the same user ID for two 
different users. Conversely, the tree connect command then also returns 
the same tree ID for each one of the (different) shares.

I think that is the root cause of the problem, leading to the 
duplication of a file ID later in the process.

My question is whether this is a Windows issue that we cannot fix, or 
whether there is a possibility to tackle this problem from Linux.

I should probably mention that both shares are mounted in parallel.

Also: the only client-controlled field that I have been able to identify 
as being the same in the bad scenario is the multiplexer ID. For both 
session setup command the MID is the same, but the process ID (and the 
user ID) is different. In the working case both the process ID and the 
MID are different.

Any hints are welcomed! ;-)


Kind regards,


Federico Sauter
Senior Firmware Programmer
-- 
Innominate Security Technologies AG
Rudower Chaussee 13 | 12489 Berlin | Germany
tel: +49 30 921028-210 | fax: +49 30 921028-020
www.innominate.com | www.twitter.com/mGuardcom

Register Court: AG Charlottenburg, HR B 81603
Management Board: Dirk Seewald | Chairman of the Supervisory Board: 
Christoph Leifer


On 05/28/2015 06:56 PM, Federico Sauter wrote:
> Greetings,
>
>
> I am using a Linux device with kernel 3.10.40. The Windows host is using
> XP PRO (32-bit,) but the problem has laso been observed with Windows 7
> 64-bit.
>
> When I directly connect the Linux device to the Windows host, a very
> strange problem arises. First of all: by "directly connect" I mean
> connecting the network cable from the device's NIC directly to the
> host's NIC, without any switch in between.
>
> The device then mounts two shares on the host: a RO share, as well as a
> RW share.
>
> The device opens a file (integrity-check-idx.tmp) for writing on the RW
> share. Then (without closing it) it scans the contents of the RO share.
> Afterwards, it writes some result on that file and flushes it before
> closing it. Straightforward enough.
>
> In the described case where the NICs are directly connected *and* that
> the Windows host finishes booting before the Linux device does,
> something strange happens. The file opened for writing is opened on FID
> 0x4002, then, when opening another file on the RO share, the same FID
> seems to be reused. That file is closed and FID 0x4002 is then invalid.
> In the end, when FID 0x4002 is flushed, an error is returned.
>
> Attached you will find an abridged version of the Wireshark capture.
> Here is the summary:
>
> SMB_COM_NT_CREATE_ANDX integrity-check-idx.tmp on FID 0x4002
> SMB_COM_READ_ANDX  FID 0x4002
> (...browse share...)
> SMB_COM_NT_CREATE_ANDX append.exe on FID 0x4002
> SMB_COM_READ_ANDX  FID 0x4002
> SMB_COM_CLOSE  FID 0x4002
> (...)
> SMB_COM_FLUSH  FID 0x4002
> Response: NT Status: STATUS_INVALID_HANDLE (0xc0000008)
>
> In the case where there is a switch between both NICs, this problem does
> not happen. In that case, FID 0x4002 is used only once for the file
> opened for writing (which was created first) and then other FIDs are
> used for each file that is opened afterwards. Thus, all operations
> succeed (which is the behavior that I would expect.)
>
> Do you have any idea on how to solve this?
>
> I am taking a deeper look at the kernel code, but so far it seems to me
> like this was a Windows problem and not a problem in our implementation,
> given that the FID is assigned by the Windows host. Could you please
> confirm that this is correct so as to provide a workaround?
>
> Thank you in advance for your kind support!
>
>
> Federico Sauter
> Senior Firmware Programmer