BUG / Possible FIX suggestion, results from investigating extra data written past expected EOF.

[John E. Malmberg]

BUG:

When the SMBD process is told to the size of a file that is being created or
overwritten, it uses ftruncate() or a fall back algorithm to set the file to
that size at the beginning of the file transfer.

Then the file is transferred and closed.

This in some circumstances is resulting in extra data that is written beyond
what was expected to be the end of file.  In most cases this data seems to
be NULL characters.

The source of this extra data has been revealed at debug level 10 to have
come from the client.  YES, the client is sending more data than it said it
was going to!


FIX SUGGESTION:
It appears that the size of the file needs to be saved until the file is
closed, and possibly used during the writing of the data to the file, to
prevent size overruns.  And then the file should be truncated just prior to
closing.


REPRODUCER:
Good old NOTEPAD shows the problem the best.  However some bad behavior is
seen with DOS EDIT and WORDPAD (AKA: WRITE).  The latter two seem to fill
the extra spaces with NULLs, so the behavior is not as apparent.

Create a small text file, about 7 lines that are about 20 characters long.
Save it.

Start up an SMBD session with logging set to LEVEL 10, or simply capture the
traces on an Ethernet analyzer.

Use NOTEPAD to edit the file to make it smaller, say remove two lines.
Modify the last line to make it clear that it is changed.

Use the SAVE option.  (NOT SAVE AS...)

Examining the file will show that some older data is present past the last
modification that you made.

Examining the log session or Ethernet traces will show that the data was in
fact sent by the SMBD client to the server to be written in to the file.

Since this was repeatable, I did some further investigation using a
debugger.

The call to ftruncate() consistently had the correct length in it that the
file should have had.

The following call to write() consistently had a longer data length in it
than was given to the ftruncate() call.  This data contained the extra
characters.


The implication here is that LANMAN is sending the resulting size of the
file to the server, and then letting the clients send some buffer of data
that could overflow the given file size, where then the server would know to
truncate it after the fact, or before it was actually written to disk.


Since I have not seen any previous discussion on this, and it does seem a
bit bizarre to me that a client would send more data, I would like to know
if anyone else can reproduce this.

I am seeing this on SAMBA 2.0.6


-John
wb8tyw at qsl.network