Flush issue with overwritten FID

[Federico Sauter <fsauter-LVkJPw3T+odGBRGhe+f61g@public.gmane.org>]

[-- 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 --]