Zero terminated unicode strings?

Mike_Kenny · November 25, 2008, 11:39am

Hi,

I just noticed, through achieving a PAGE_FAULT_IN_NONE_PAGED_AREA BSOD, that I’d been slightly foolish.
I’d assumed in one part of my code that UNICODE_STRINGS were zero terminated strings.
This, certainly isn’t the case for UNICODE_STRINGS returned from a call to:

status = FltGetFileNameInformation( pData,
FLT_FILE_NAME_NORMALIZED |
FLT_FILE_NAME_QUERY_ALWAYS_ALLOW_CACHE_LOOKUP,
&pFileNameInformation );

pFileNameInformation->Name is not zero terminated, especially noticable in dbg builds (checked) where my memory allocator fills memory with 0xcd on allocation.

I noticed this when passing pFileNameInformation->Name to a LPCWCHAR* function of my own construction, which assumed a zero terminator - hence the 0xffff max size of the buffer was walked passed and a BSOD ensued.

I am now searching for other places where such assumtions about unicode strings have been made.

My question is, is this (as has been proved in this instance) the correct assumption? Or is there a problem with FltGetFileNameInformation(); // highly unlikely.

So, digging Buffer from:

typedef struct _LSA_UNICODE_STRING {
USHORT Length;
USHORT MaximumLength;
PWSTR Buffer;
} LSA_UNICODE_STRING, *PLSA_UNICODE_STRING, UNICODE_STRING, *PUNICODE_STRING;

and passing it to wcslen() for example would { discounting a) being completely dumb, as of course thats Length/sizeof(WCHAR) }, also be b) v. dangerous.

Just thought I’d post this up for comments.
I suppose its a case of RTM. However, I’m very surprised I’ve not had this type of crash much earlier.

Mike

Don_Burn_1 · November 25, 2008, 11:41am

You can never assume a UNICODE_STRING is terminated. As you have seen this
is a great way to BSOD.

–
Don Burn (MVP, Windows DDK)
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply

wrote in message news:xxxxx@ntfsd…
> Hi,
>
> I just noticed, through achieving a PAGE_FAULT_IN_NONE_PAGED_AREA BSOD,
> that I’d been slightly foolish.
> I’d assumed in one part of my code that UNICODE_STRINGS were zero
> terminated strings.
> This, certainly isn’t the case for UNICODE_STRINGS returned from a call
> to:
>
> status = FltGetFileNameInformation( pData,
> FLT_FILE_NAME_NORMALIZED |
> FLT_FILE_NAME_QUERY_ALWAYS_ALLOW_CACHE_LOOKUP,
> &pFileNameInformation );
>
> pFileNameInformation->Name is not zero terminated, especially noticable in
> dbg builds (checked) where my memory allocator fills memory with 0xcd on
> allocation.
>
> I noticed this when passing pFileNameInformation->Name to a LPCWCHAR*
> function of my own construction, which assumed a zero terminator - hence
> the 0xffff max size of the buffer was walked passed and a BSOD ensued.
>
> I am now searching for other places where such assumtions about unicode
> strings have been made.
>
> My question is, is this (as has been proved in this instance) the correct
> assumption? Or is there a problem with FltGetFileNameInformation(); //
> highly unlikely.
>
> So, digging Buffer from:
>
> typedef struct _LSA_UNICODE_STRING {
> USHORT Length;
> USHORT MaximumLength;
> PWSTR Buffer;
> } LSA_UNICODE_STRING, *PLSA_UNICODE_STRING, UNICODE_STRING,
> *PUNICODE_STRING;
>
> and passing it to wcslen() for example would { discounting a) being
> completely dumb, as of course thats Length/sizeof(WCHAR) }, also be b) v.
> dangerous.
>
> Just thought I’d post this up for comments.
> I suppose its a case of RTM. However, I’m very surprised I’ve not had this
> type of crash much earlier.
>
> Mike
>

Ken_Johnson · November 25, 2008, 11:46am

There is in general never a guarantee that UNICODE_STRING has a null beyond the last character in the buffer. The assumption that you may treat all such strings as C-style zero terminated strings is invalid.

S

-----Original Message-----
From: xxxxx@scee.net
Sent: Tuesday, November 25, 2008 10:38
To: Windows File Systems Devs Interest List
Subject: [ntfsd] Zero terminated unicode strings?

Hi,

I just noticed, through achieving a PAGE_FAULT_IN_NONE_PAGED_AREA BSOD, that I’d been slightly foolish.
I’d assumed in one part of my code that UNICODE_STRINGS were zero terminated strings.
This, certainly isn’t the case for UNICODE_STRINGS returned from a call to:

status = FltGetFileNameInformation( pData,
FLT_FILE_NAME_NORMALIZED |
FLT_FILE_NAME_QUERY_ALWAYS_ALLOW_CACHE_LOOKUP,
&pFileNameInformation );

pFileNameInformation->Name is not zero terminated, especially noticable in dbg builds (checked) where my memory allocator fills memory with 0xcd on allocation.

I noticed this when passing pFileNameInformation->Name to a LPCWCHAR* function of my own construction, which assumed a zero terminator - hence the 0xffff max size of the buffer was walked passed and a BSOD ensued.

I am now searching for other places where such assumtions about unicode strings have been made.

My question is, is this (as has been proved in this instance) the correct assumption? Or is there a problem with FltGetFileNameInformation(); // highly unlikely.

So, digging Buffer from:

typedef struct _LSA_UNICODE_STRING {
USHORT Length;
USHORT MaximumLength;
PWSTR Buffer;
} LSA_UNICODE_STRING, *PLSA_UNICODE_STRING, UNICODE_STRING, *PUNICODE_STRING;

and passing it to wcslen() for example would { discounting a) being completely dumb, as of course thats Length/sizeof(WCHAR) }, also be b) v. dangerous.

Just thought I’d post this up for comments.
I suppose its a case of RTM. However, I’m very surprised I’ve not had this type of crash much earlier.

Mike

—
NTFSD is sponsored by OSR

For our schedule debugging and file system seminars
(including our new fs mini-filter seminar) visit:
http://www.osr.com/seminars

You are currently subscribed to ntfsd as: xxxxx@valhallalegends.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

Mark_S_Edwards · November 25, 2008, 11:50am

Mike,

Search the ntdev archives, I recall a thread on this topic a couple
of years back.

The upshot was that under no circumstances can you expect that a
system returned UNICODE_STRING will be null terminated. You’ve come
across one call type, another class of calls are values returned from registry.

The only time you can guarantee a null terminated buffer in the
UNICODE_STRING is if you construct it yourself. I would guess this
has been one of the larger classes of driver fault.

If you really do have to use string function, copy the buffer to
somewhere local and ensure null termination and although a pain at
first, I’ve found the strsafe functions to be invaluable.

Cheers,

Mark.

At 16:37 25/11/2008, xxxxx@scee.net wrote:

Hi,

I just noticed, through achieving a PAGE_FAULT_IN_NONE_PAGED_AREA
BSOD, that I’d been slightly foolish.
I’d assumed in one part of my code that UNICODE_STRINGS were zero
terminated strings.
This, certainly isn’t the case for UNICODE_STRINGS returned from a call to:

status = FltGetFileNameInformation( pData,
FLT_FILE_NAME_NORMALIZED |
FLT_FILE_NAME_QUERY_ALWAYS_ALLOW_CACHE_LOOKUP,
&pFileNameInformation );

pFileNameInformation->Name is not zero terminated, especially
noticable in dbg builds (checked) where my memory allocator fills
memory with 0xcd on allocation.

I noticed this when passing pFileNameInformation->Name to a
LPCWCHAR* function of my own construction, which assumed a zero
terminator - hence the 0xffff max size of the buffer was walked
passed and a BSOD ensued.

I am now searching for other places where such assumtions about
unicode strings have been made.

My question is, is this (as has been proved in this instance) the
correct assumption? Or is there a problem with
FltGetFileNameInformation(); // highly unlikely.

So, digging Buffer from:

typedef struct _LSA_UNICODE_STRING {
USHORT Length;
USHORT MaximumLength;
PWSTR Buffer;
}
LSA_UNICODE_STRING, *PLSA_UNICODE_STRING, UNICODE_STRING, *PUNICODE_STRING;

and passing it to wcslen() for example would { discounting a) being
completely dumb, as of course thats Length/sizeof(WCHAR) }, also be
b) v. dangerous.

Just thought I’d post this up for comments.
I suppose its a case of RTM. However, I’m very surprised I’ve not
had this type of crash much earlier.

Mike

Mike_Kenny · November 25, 2008, 12:47pm

Thanks for the info everyone.

I believe I’ve been lucky so far, through use of my own UtilUnicodeString functions and construction, of avoiding this issue. However, somewhat to my own embarrasment I see now the error of my ways.
To provide a length and then waste memory with additional two byte zeros seems somewhat ott (even for me). PASCAL + C = Rather Unlikely Combination.

Mike

OSR_Community_User · November 25, 2008, 1:15pm

Wasting space, oh, yes, this is a really serious issue. Let’s see: in a
machine with 2GB physical memory, 2bytes additional space…each
NUL-terminated string wastes 0.0000001% of the total address space…you
know, if you had a billion strings this could be a serious problem…

My impression of the reason UNICODE_STRING works as it does was to allow
substrings of a larger string (e.g., a directory path) to be represented
without requiring allocation-and-copy to get a NUL-terminated substring. It
was certainly not done for the purpose of saving the space of the
termination characters (hmmm…12 bytes for a UNICODE_STRING structure to
save 2 bytes of NUL termination, yes, that’s a good tradeoff, let’s do it
that way…each string now takes only 10 additional bytes. Why, we’re down
from allowing a billion strings to only 100 million…). The other reason
was to prevent the classic buffer-overrun because each string carried its
buffer size with it, and with proper use of the calls, buffer overrun would
be impossible. Neither of these goals have anything to do with saving the
NUL terminator space.
joe

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@scee.net
Sent: Tuesday, November 25, 2008 12:46 PM
To: Windows File Systems Devs Interest List
Subject: RE:[ntfsd] Zero terminated unicode strings?

Thanks for the info everyone.

I believe I’ve been lucky so far, through use of my own UtilUnicodeString
functions and construction, of avoiding this issue. However, somewhat to my
own embarrasment I see now the error of my ways.
To provide a length and then waste memory with additional two byte zeros
seems somewhat ott (even for me). PASCAL + C = Rather Unlikely Combination.

Mike

NTFSD is sponsored by OSR

For our schedule debugging and file system seminars
(including our new fs mini-filter seminar) visit:
http://www.osr.com/seminars

You are currently subscribed to ntfsd as: xxxxx@flounder.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

–
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

OSR_Community_User · November 25, 2008, 3:37pm

Just to amplify what Mark said a little bit, the registry strings (REG_SZ & REG_MULTI_SZ) are
supposed to be null terminated, but they just aren’t always in practice.

Good luck,

mm

Mark S. Edwards wrote:

Mike,

Search the ntdev archives, I recall a thread on this topic a couple of
years back.

The upshot was that under no circumstances can you expect that a system
returned UNICODE_STRING will be null terminated. You’ve come across one
call type, another class of calls are values returned from registry.

The only time you can guarantee a null terminated buffer in the
UNICODE_STRING is if you construct it yourself. I would guess this has
been one of the larger classes of driver fault.

If you really do have to use string function, copy the buffer to
somewhere local and ensure null termination and although a pain at
first, I’ve found the strsafe functions to be invaluable.

Cheers,

Mark.

At 16:37 25/11/2008, xxxxx@scee.net wrote:
> Hi,
>
> I just noticed, through achieving a PAGE_FAULT_IN_NONE_PAGED_AREA
> BSOD, that I’d been slightly foolish.
> I’d assumed in one part of my code that UNICODE_STRINGS were zero
> terminated strings.
> This, certainly isn’t the case for UNICODE_STRINGS returned from a
> call to:
>
> status = FltGetFileNameInformation( pData,
> FLT_FILE_NAME_NORMALIZED |
> FLT_FILE_NAME_QUERY_ALWAYS_ALLOW_CACHE_LOOKUP,
> &pFileNameInformation );
>
> pFileNameInformation->Name is not zero terminated, especially
> noticable in dbg builds (checked) where my memory allocator fills
> memory with 0xcd on allocation.
>
> I noticed this when passing pFileNameInformation->Name to a LPCWCHAR*
> function of my own construction, which assumed a zero terminator -
> hence the 0xffff max size of the buffer was walked passed and a BSOD
> ensued.
>
> I am now searching for other places where such assumtions about
> unicode strings have been made.
>
> My question is, is this (as has been proved in this instance) the
> correct assumption? Or is there a problem with
> FltGetFileNameInformation(); // highly unlikely.
>
> So, digging Buffer from:
>
> typedef struct _LSA_UNICODE_STRING {
> USHORT Length;
> USHORT MaximumLength;
> PWSTR Buffer;
> } LSA_UNICODE_STRING, *PLSA_UNICODE_STRING, UNICODE_STRING,
> *PUNICODE_STRING;
>
> and passing it to wcslen() for example would { discounting a) being
> completely dumb, as of course thats Length/sizeof(WCHAR) }, also be b)
> v. dangerous.
>
> Just thought I’d post this up for comments.
> I suppose its a case of RTM. However, I’m very surprised I’ve not had
> this type of crash much earlier.
>
> Mike

Lyndon_J_Clarke-2 · November 25, 2008, 4:02pm

Let me add to the clamour … just forget about zero terminated strings in
kernel mode … and when you got used to that avoid zero terminated strings
in user mode unless these are mandated by the api you are using

The approach I’ve adopted for passing string data between kernel mode and
user mode is that I have zero terminated unicode string with a character (or
byte) count which includes zero terminator. I dont use the zero terminator
in kernel mode - I use the count. I use the zero terminator in user mode
when I have no choice - if I have no choice, then it’s there. The count is
always the size of the buffer I need to store the thing.

wrote in message news:xxxxx@ntfsd…
> Hi,
>
> I just noticed, through achieving a PAGE_FAULT_IN_NONE_PAGED_AREA BSOD,
> that I’d been slightly foolish.
> I’d assumed in one part of my code that UNICODE_STRINGS were zero
> terminated strings.
> This, certainly isn’t the case for UNICODE_STRINGS returned from a call
> to:
>
> status = FltGetFileNameInformation( pData,
> FLT_FILE_NAME_NORMALIZED |
> FLT_FILE_NAME_QUERY_ALWAYS_ALLOW_CACHE_LOOKUP,
> &pFileNameInformation );
>
> pFileNameInformation->Name is not zero terminated, especially noticable in
> dbg builds (checked) where my memory allocator fills memory with 0xcd on
> allocation.
>
> I noticed this when passing pFileNameInformation->Name to a LPCWCHAR*
> function of my own construction, which assumed a zero terminator - hence
> the 0xffff max size of the buffer was walked passed and a BSOD ensued.
>
> I am now searching for other places where such assumtions about unicode
> strings have been made.
>
> My question is, is this (as has been proved in this instance) the correct
> assumption? Or is there a problem with FltGetFileNameInformation(); //
> highly unlikely.
>
> So, digging Buffer from:
>
> typedef struct _LSA_UNICODE_STRING {
> USHORT Length;
> USHORT MaximumLength;
> PWSTR Buffer;
> } LSA_UNICODE_STRING, *PLSA_UNICODE_STRING, UNICODE_STRING,
> *PUNICODE_STRING;
>
> and passing it to wcslen() for example would { discounting a) being
> completely dumb, as of course thats Length/sizeof(WCHAR) }, also be b) v.
> dangerous.
>
> Just thought I’d post this up for comments.
> I suppose its a case of RTM. However, I’m very surprised I’ve not had this
> type of crash much earlier.
>
> Mike
>

OSR_Community_User · November 25, 2008, 4:18pm

In general, the only time you ever see a NUL-terminated string in the kernel
is when you use RtlInitUnicodeString to initialize from a string literal.

When returning strings to user space, it is whatever you have told the user
to expect in terms of return value. In general, most I/O operations do not
guarantee NUL-termination, and users are accustomed to writing something
like

BYTE buffer[MAX_SIZE + 1];
if(!ReadFile(h, buffer, MAX_SIZE, &bytesRead, NULL))
… deal with error
else
{
buffer[bytesRead] = 0;
}

so it is rarely an issue. Note also that this works correctly only for ANSI
input (or MAX_SIZE + sizeof(TCHAR) and store two 0 bytes, left as an
Exercise For The Reader, see below)

At least, since I tend to spend most of my life in user space, that’s what I
write, what I see others writing, and what I teach.

Note that the ANSI/Unicode issue does arise, since
ReadFile/WriteFile/DeviceIoControl are byte-oriented and there is no
marshalling based on the type of call (the Registry calls will do
marshalling of Unicode to ANSI on reads and ANSI to Unicode on writes), but
there’s no ReadFileA/ReadFileW etc.

When using the Undocumented Windows API (Nebbett) from user space, there are
UNICODE_STRINGs returned for APIs that return strings, and they are
definitely *not* NUL-terminated. I’ve done this, and examined the return
values with the debugger.
joe

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Lyndon J Clarke
Sent: Tuesday, November 25, 2008 4:01 PM
To: Windows File Systems Devs Interest List
Subject: Re:[ntfsd] Zero terminated unicode strings?

Let me add to the clamour … just forget about zero terminated strings in
kernel mode … and when you got used to that avoid zero terminated strings

in user mode unless these are mandated by the api you are using

The approach I’ve adopted for passing string data between kernel mode and
user mode is that I have zero terminated unicode string with a character (or

byte) count which includes zero terminator. I dont use the zero terminator
in kernel mode - I use the count. I use the zero terminator in user mode
when I have no choice - if I have no choice, then it’s there. The count is
always the size of the buffer I need to store the thing.

wrote in message news:xxxxx@ntfsd…
> Hi,
>
> I just noticed, through achieving a PAGE_FAULT_IN_NONE_PAGED_AREA BSOD,
> that I’d been slightly foolish.
> I’d assumed in one part of my code that UNICODE_STRINGS were zero
> terminated strings.
> This, certainly isn’t the case for UNICODE_STRINGS returned from a call
> to:
>
> status = FltGetFileNameInformation( pData,
> FLT_FILE_NAME_NORMALIZED |
> FLT_FILE_NAME_QUERY_ALWAYS_ALLOW_CACHE_LOOKUP,
> &pFileNameInformation );
>
> pFileNameInformation->Name is not zero terminated, especially noticable in

> dbg builds (checked) where my memory allocator fills memory with 0xcd on
> allocation.
>
> I noticed this when passing pFileNameInformation->Name to a LPCWCHAR*
> function of my own construction, which assumed a zero terminator - hence
> the 0xffff max size of the buffer was walked passed and a BSOD ensued.
>
> I am now searching for other places where such assumtions about unicode
> strings have been made.
>
> My question is, is this (as has been proved in this instance) the correct
> assumption? Or is there a problem with FltGetFileNameInformation(); //
> highly unlikely.
>
> So, digging Buffer from:
>
> typedef struct _LSA_UNICODE_STRING {
> USHORT Length;
> USHORT MaximumLength;
> PWSTR Buffer;
> } LSA_UNICODE_STRING, *PLSA_UNICODE_STRING, UNICODE_STRING,
> *PUNICODE_STRING;
>
> and passing it to wcslen() for example would { discounting a) being
> completely dumb, as of course thats Length/sizeof(WCHAR) }, also be b) v.
> dangerous.
>
> Just thought I’d post this up for comments.
> I suppose its a case of RTM. However, I’m very surprised I’ve not had this

> type of crash much earlier.
>
> Mike
>

—
NTFSD is sponsored by OSR

For our schedule debugging and file system seminars
(including our new fs mini-filter seminar) visit:
http://www.osr.com/seminars

You are currently subscribed to ntfsd as: xxxxx@flounder.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

–
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

Ken_Johnson · November 25, 2008, 4:29pm

The whole registry storing nulls in string values is a big cluster, IMO. I suspect the problem has its roots in the awkward termination characteristics expected of REG_MULTI_SZ. If it were not for that, it would have been much better off were strings in the registry never having been “guaranteed” to be null terminated. I say “guaranteed”, because although that’s what you’re SUPPOSED to see, you might not see it, in which case you need to handle it anyway or risk compromising the system (if the value could be set by an untrusted user mode caller).

Null termination here in the registry is tricky, because while the string value in the registry is supposed to be null terminated, you probably do NOT want to include the terminating null in the actual string you get back from the registry. So you need to check for a terminating null and decrement the length of the buffer appropriately. But you don’t want to do that if you got back a buffer length < 2, or you’d underrun.

To make matters even more fun, user mode code has been (in)famous for misusing the registry APIs for years and forgetting to include null termination in the registry APIs for RegSetValue(Ex). To make matters even *more* interesting, they usually got away with it if they were using the ANSI (RegSetValue(Ex)A) versions, because those internally copied the user supplied string to an internal Unicode buffer, expanded it, and then applied the correct (Unicode string) null termination before passing the buffer to the raw system service, thus papering over the fact that their callers were broken. The Unicode (RegSetValueEx(W)) APIs did not used to do this (IIRC), though they now do for compatibility with porting Win9x apps to Unicode APIs, where said Win9x apps sized their strings wrong.

Even with the compatibility hacks, it is STILL possible for an evil user mode caller to call the system service directly without specifying a null terminiator.

There is a similar, equally delightful series of “worked-by-accident-until-I-was-Unicode” and other fun things with respect to user mode apps retrieving registry strings and not just setting them, IIRC.

The net of all of this is:

You might get back an empty string from the registry API (length zero). In this case, you shouldn’t try to strip the null terminator from it or you’d decrease the length of your UNICODE_STRING below zero, resulting in badness.
You might get back a string with a length that isn’t a legal multiple of WCHAR, which you need to handle, as CM doesn’t sanitize it for you.
You might get back a string with a missing null terminator if you’re using the Unicode build of a buggy app on an old OS (IIRC), in which case you probably *also* don’t want to try and chop off the extra null terminator before saving the string away in a UNICODE_STRING. Alternatively, you could just consider the registry data just plain bogus here and not handle this case.
You could get back a well-formed registry string with a null terminator, at which point you probably want to chop off the null terminator before storing the string in a UNICODE_STRING structure. (Otherwise, if it was, say, a filename, you might try to create a file with a null at the end of the filename, which wouldn’t be very nice.)

Like I said, registry and null terminated strings is a big black morass.

S

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Lyndon J Clarke
Sent: Tuesday, November 25, 2008 4:01 PM
To: Windows File Systems Devs Interest List
Subject: Re:[ntfsd] Zero terminated unicode strings?

Let me add to the clamour … just forget about zero terminated strings in
kernel mode … and when you got used to that avoid zero terminated strings
in user mode unless these are mandated by the api you are using

The approach I’ve adopted for passing string data between kernel mode and
user mode is that I have zero terminated unicode string with a character (or
byte) count which includes zero terminator. I dont use the zero terminator
in kernel mode - I use the count. I use the zero terminator in user mode
when I have no choice - if I have no choice, then it’s there. The count is
always the size of the buffer I need to store the thing.

wrote in message news:xxxxx@ntfsd…
> Hi,
>
> I just noticed, through achieving a PAGE_FAULT_IN_NONE_PAGED_AREA BSOD,
> that I’d been slightly foolish.
> I’d assumed in one part of my code that UNICODE_STRINGS were zero
> terminated strings.
> This, certainly isn’t the case for UNICODE_STRINGS returned from a call
> to:
>
> status = FltGetFileNameInformation( pData,
> FLT_FILE_NAME_NORMALIZED |
> FLT_FILE_NAME_QUERY_ALWAYS_ALLOW_CACHE_LOOKUP,
> &pFileNameInformation );
>
> pFileNameInformation->Name is not zero terminated, especially noticable in
> dbg builds (checked) where my memory allocator fills memory with 0xcd on
> allocation.
>
> I noticed this when passing pFileNameInformation->Name to a LPCWCHAR*
> function of my own construction, which assumed a zero terminator - hence
> the 0xffff max size of the buffer was walked passed and a BSOD ensued.
>
> I am now searching for other places where such assumtions about unicode
> strings have been made.
>
> My question is, is this (as has been proved in this instance) the correct
> assumption? Or is there a problem with FltGetFileNameInformation(); //
> highly unlikely.
>
> So, digging Buffer from:
>
> typedef struct _LSA_UNICODE_STRING {
> USHORT Length;
> USHORT MaximumLength;
> PWSTR Buffer;
> } LSA_UNICODE_STRING, *PLSA_UNICODE_STRING, UNICODE_STRING,
> *PUNICODE_STRING;
>
> and passing it to wcslen() for example would { discounting a) being
> completely dumb, as of course thats Length/sizeof(WCHAR) }, also be b) v.
> dangerous.
>
> Just thought I’d post this up for comments.
> I suppose its a case of RTM. However, I’m very surprised I’ve not had this
> type of crash much earlier.
>
> Mike
>

—
NTFSD is sponsored by OSR

For our schedule debugging and file system seminars
(including our new fs mini-filter seminar) visit:
http://www.osr.com/seminars

You are currently subscribed to ntfsd as: xxxxx@valhallalegends.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

Ken_Johnson · November 25, 2008, 4:32pm

Just to be extra clear and clarify Joe’s statement here, RtlInitUnicodeString does NOT include the null terminator in the string that it has initialized. “The string” is defined as [UnicodeString->Buffer, (PWCHAR)((PCHAR)UnicodeString->Buffer + UnicodeString->Length)].

The *buffer* may have a null at the end of it, but as far as the UNICODE_STRING struct is there, it won’t be included in the buffer count.

Joe is referring to the C-style string argument to RtlInitUnicodeString, which is indeed null terminated. The resultant UNICODE_STRING structure does not include the terminating null byte in its count, however.

S

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Joseph M. Newcomer
Sent: Tuesday, November 25, 2008 4:18 PM
To: Windows File Systems Devs Interest List
Subject: RE: [ntfsd] Zero terminated unicode strings?