Deeper insight into RtlInitUnicodeString, WEIRD buffer behaviour

Hey I am experimenting with Unicode String a bit and I found a really weird behaviour…prolly a bug!
I expected the Unicode Init Method to copy the Buffer over but what happens in the following example code is simply unbelieveable:

PWCHAR pBuffer = (PWCHAR)ExAllocatePool(NonPagedPool,50*sizeof(WCHAR)); // 50 WCHARs should be more than enough for this name + 0x00 0x00

LARGE_INTEGER p = KeQueryPerformanceCounter(NULL);
int random = p.LowPart ^ p.HighPart;

if(pBuffer==NULL){
// EXALLOCATE FAILED, GIVE BACK SOME BOGUS STRING!
RtlInitUnicodeString(myUnicode,L"\SystemRoot\BogusFile");
return;
}

RtlStringCchPrintfW(pBuffer,50,L"\SystemRoot\cc-%d.dcg.ttf",random);

RtlInitUnicodeString(myUnicode,pBuffer);
DbgPrint(“Test1: %wZ\n”,myUnicode);
ExFreePool(pBuffer);
DbgPrint(“Test2: %wZ\n”,myUnicode);

Alright the surprizing output is:
Test1: \SystemRoot\cc-75263875.dcg.ttf
Test2: ??ystemRoot\cc-75263875.dcg.ttf

So freeing the temporary buffer results in changing the first 2 chars in the Unicodestring itself.

Isnt that weird?

Re-read the docs on RtlInitUnicodeString in the following link. Pay very
close attention to the first sentence after “COMMENTS” and look at what your
destination buffer is being initialized to.

http://www.osronline.com/DDKx/kmarch/k109_6x4i.htm

Please note that you are assigning your temporary buffer as the unicode string buffer itself.

When you call RtlInitUnicodeString you are actually doing the following:

myUnicode ->Buffer = pBuffer;

Now try to figure out what happens if you free pBuffer!

-----Mensaje original-----
De: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] En nombre de xxxxx@web.de
Enviado el: lunes, 01 de octubre de 2007 10:14
Para: Windows File Systems Devs Interest List
Asunto: [ntfsd] Deeper insight into RtlInitUnicodeString, WEIRD buffer behaviour

Hey I am experimenting with Unicode String a bit and I found a really weird behaviour…prolly a bug!
I expected the Unicode Init Method to copy the Buffer over but what happens in the following example code is simply unbelieveable:

PWCHAR pBuffer = (PWCHAR)ExAllocatePool(NonPagedPool,50*sizeof(WCHAR)); // 50 WCHARs should be more than enough for this name + 0x00 0x00

LARGE_INTEGER p = KeQueryPerformanceCounter(NULL);
int random = p.LowPart ^ p.HighPart;

if(pBuffer==NULL){
// EXALLOCATE FAILED, GIVE BACK SOME BOGUS STRING!
RtlInitUnicodeString(myUnicode,L"\SystemRoot\BogusFile");
return;
}

RtlStringCchPrintfW(pBuffer,50,L"\SystemRoot\cc-%d.dcg.ttf",random);

RtlInitUnicodeString(myUnicode,pBuffer);
DbgPrint(“Test1: %wZ\n”,myUnicode);
ExFreePool(pBuffer);
DbgPrint(“Test2: %wZ\n”,myUnicode);

Alright the surprizing output is:
Test1: \SystemRoot\cc-75263875.dcg.ttf
Test2: ??ystemRoot\cc-75263875.dcg.ttf

So freeing the temporary buffer results in changing the first 2 chars in the Unicodestring itself.

Isnt that weird?


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@pandasecurity.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

This is expected behavior, let me explain:

RtlInitUnicodeString(us, sz) basically does this:

us.MaximumLength = (wcslen(sz) + 1) * sizeof(WCHAR);
us.Length = wcslen(sz) * sizeof(WCHAR);
us.Buffer = sz;

So in your case, the result unicode string contains
the buffer allocated by ExAllocatePool. If you free
the buffer:

RtlInitUnicodeString(myUnicode,pBuffer);
DbgPrint(“Test1: %wZ\n”,myUnicode);
ExFreePool(pBuffer);
DbgPrint(“Test2: %wZ\n”,myUnicode);

the myUnicode.Buffer is still non-NULL but points to freed memory.
You are lucky that you haven’t got BSOD.

L.

Okay I unserstand that, but that still does not explain why only 2 chars are freed and the rest gets still printed out correctly.