Project

General

Profile

Bug #13572

SMB Query FileFsVolumeInformation should allow truncation

Added by Gordon Ross 16 days ago. Updated 9 days ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
-
Start date:
Due date:
% Done:

100%

Estimated time:
Difficulty:
Medium
Tags:
Gerrit CR:

Description

Description:
This behaviour can only be seen on recent Windows 10 1903 builds, including 18362.295. We have an existing file and we try to open it with Notepad, VCS or python. We will see an error that tells us file can't be found, for Notepad it says "The system cannot find the file specified". When we try to open the same file with Notepad++ everything is fine. Also, Windows Explorer shows us file contents in preview window.

Steps to Reproduce:
Install Windows 10 1903 update. (Windows 1903 OS BUILD 18362.295)
Try to open file with Notepad, VCS, python (os.stat()). Probably other apps are having problems too.

Update: Turns out reproduction requires setting this Windows registry key:
HKLM/SYSTEM/CurrentControlSet/Services/LanmanWorkstation/Parameters
FileInfoCacheLifetime DWORD 0
Without that registry key/value the client works fine.

Expected Results:
File gets opened.

Actual Results:
File doesn't get open.


Files

win10nocache4.snoop (34.2 KB) win10nocache4.snoop Gordon Ross, 2021-02-20 11:18 PM
win10nocache8.snoop (213 KB) win10nocache8.snoop Gordon Ross, 2021-02-20 11:18 PM
#1

Updated by Gordon Ross 16 days ago

It turns out the problem here was how we handle the case where the client sends an SMB2 Query Info FS with level FileFsVolumeInformation when the specified maximum output space is smaller than the size of a full response. (This is a pretty weird case, protocol-wise.) When the output won't fit, we're supposed to return a truncated response, and STATUS_BUFFER_OVERFLOW

There are two captures attached, before and after the fix.
win10nocache4.snoop win10nocache8.snoop
In frame 118 of ...4.snoop one can see that we return an 18 byte response with no label (because the label woudl not fix)
In frame 175 of ...8.snoop one can see that we return a 24 byte response with the label truncated and the correct status.
With that fix, the Windows 10 client is happy enough to open the file.

While working with MS on this, we found that we should also fill in the
"Volume Create Time" field in this response. Fixed with this change.

Getting truncation to work the way we want while building responses is a little tricky, so this adds some tests to exercise those support functions under truncating conditions.

#3

Updated by Electric Monk 16 days ago

  • Gerrit CR set to 1278
#4

Updated by Gordon Ross 10 days ago

Testing:
Open file on Windows 10 client per. the issue description. (Open succeeds.)

Added test case "smb2.getinfo.qfs1_buffer24" to smbtorture
in github.com/gwr/samba gwr-eng-tort2a
Running that case before the fix fails, after OK.

#5

Updated by Gordon Ross 10 days ago

  • Status changed from In Progress to Pending RTI
#6

Updated by Electric Monk 9 days ago

  • Status changed from Pending RTI to Closed
  • % Done changed from 0 to 100

git commit 25a9a7aaf35c7e4a2b5a57d3875af906147710d5

commit  25a9a7aaf35c7e4a2b5a57d3875af906147710d5
Author: Gordon Ross <gwr@nexenta.com>
Date:   2021-02-27T18:33:24.000Z

    13572 SMB Query FileFsVolumeInformation should allow truncation
    Reviewed by: Matt Barden <matt.barden@nexenta.com>
    Reviewed by: Yuri Pankov <yuri.pankov@nexenta.com>
    Reviewed by: C Fraire <cfraire@me.com>
    Approved by: Robert Mustacchi <rm@fingolfin.org>

Also available in: Atom PDF