Hi,
I encountered a use case when FltGetFileNameInformation with "Normalized" returns a wrong path.
The setup:
A Win 10 VM running on a Win 10 host.
A network share mapped to a drive letter in the VM to the host (example: map Z: to \\192.168.44.1\e$).
browse z: and try to run a file.
I have a filter manager that calls FltGetFileNameInformation(.. FLT_FILE_NAME_NORMALIZED | FLT_FILE_NAME_QUERY_FILESYSTEM_ONL, ...) in PostCreate callback.
Behavior:
(the description below is using a tester, the issue occurred during Win 10 explorer operations)
A user space process opens a file (FileHandle), then another open is performed:
InitializeObjectAttributes(&ObjectAttributes,
(PUNICODE_STRING)&NullFile,
OBJ_CASE_INSENSITIVE,
FileHandle,
NULL);
Status = ZwOpenFile(&NewFileHandle,
GENERIC_READ,
&ObjectAttributes,
&IoStatusBlock,
FILE_SHARE_READ | FILE_SHARE_WRITE | FILE_SHARE_DELETE,
0);
In the PostCreate callback the FileObject has a FileName with length 0.
The RelatedFileObject is the one from the first create (FileName \;z:\........)
The result of FileNormalizedNameInformation is:
kd> dx -r1 ((cyvrfsfd!_FLT_FILE_NAME_INFORMATION *)0xb16311dc)
((cyvrfsfd!_FLT_FILE_NAME_INFORMATION *)0xb16311dc) : 0xb16311dc [Type: _FLT_FILE_NAME_INFORMATION *]
[+0x000] Size : 0x40 [Type: unsigned short]
[+0x002] NamesParsed : 0x0 [Type: unsigned short]
[+0x004] Format : 0x1 [Type: unsigned long]
[+0x008] Name : "\Device\Mup" [Type: _UNICODE_STRING]
[+0x010] Volume : "\Device\Mup" [Type: _UNICODE_STRING]
[+0x018] Share : "" [Type: _UNICODE_STRING]
[+0x020] Extension : "" [Type: _UNICODE_STRING]
[+0x028] Stream : "" [Type: _UNICODE_STRING]
[+0x030] FinalComponent : "" [Type: _UNICODE_STRING]
[+0x038] ParentDir : "" [Type: _UNICODE_STRING]
Note that the returned path is the device path (not the file path)
Root cause:
After Microsoft added support for FileNormalizedNameInformation the code of FltpGetFileName changed (in Windows 8.1)
In Windows 7 FltpGetFileName callced FltpQueryInformationFile, and this call succeeded the the result was Ok (no bug).
In Windows 8.1 (and Win 10):
00 979cf6f4 89097cda fltmgr!FltpGetFileName+0x199
01 979cf704 89094f62 fltmgr!FltpGetOpenedFileName+0x18
02 979cf720 89097d5c fltmgr!FltpCallOpenedFileNameHandler+0x8a
03 979cf73c 89098505 fltmgr!FltpGetNormalizedFileNameWorker+0x16
04 979cf754 89095765 fltmgr!FltpGetNormalizedFileName+0x19
05 979cf76c 890958a8 fltmgr!FltpCreateFileNameInformation+0x81
06 979cf780 8907fe1e fltmgr!CreateTemporaryFileNameInformation+0x4e
07 979cf7b0 8907ffa3 fltmgr!FltpGetFileNameInformation+0x61e
08 979cf7d8 b1917e0d fltmgr!FltGetFileNameInformation+0x12b
FltpGetFileName sends a QueryInformation IRP with InfoCalss set to Normalized. This request fails with STATUS_NOT_SUPPORTED.
The problem is that the code in FltpGetFileName ignores the failure and reaches an if statement:
if (Data && FltpOperationFlags(.....) & 2 && PostOperation && !FileObject->FileName.Length)
{
*SystemBuffer = 0; // SytemBuffer points to FILE_NAME_INFORMATION struct
// Code that concatenates the device name to the path resolved (which is empty in this case because it failed)
return STATUS_SUCCESS;
}
The function meant to try first with Normalized and if not supported try with Opened but the problem is that after it returns not supported for Normalized is returns a faulty result.
Any chance there is a Microsoft engineer here that could take a look at this.
Thanks,
Amin
