Bug in the FSRTL library

NTFSD
1

I found the following bug in the RTL. I thought I would post to save
someone else the grief that I went through finding it. This bug is
present in NT4 and W2k. I have not tested it in XP, but i would be
surprised if it is not there also.

The FsRtl LargeMcb functions don’t utilize the upper 32 bits of the LBN.
They are totally ignored as if they were 0. Here is code that demonstrates
the problem:

LARGE_MCB mcb;
FsRtlInitializeLargeMcb (&mcb, PagedPool);

FsRtlAddLargeMcbEntry (&mcb, 0, 0, 0x1000);
FsRtlAddLargeMcbEntry (&mcb, 0x1000, 0x1111111111111000, 0x1000);
FsRtlAddLargeMcbEntry (&mcb, 0x2000, 0x2222222222222000, 0x1000);
FsRtlAddLargeMcbEntry (&mcb, 0x3000, 0x3333333333333000, 0x1000);

LONGLONG vbo, lbo, size;
for (int i = 0; FsRtlGetNextLargeMcbEntry (&mcb, i, &vbo, &lbo, &size);
i++)
{
DbgPrintLongLong (vbo);
DbgPrintLongLong (lbo);
DbgPrintLongLong (size);
}

The output from this is:
0x0000000000000000
0x0000000000000000
0x0000000000001000

0x0000000000001000
0x0000000011111000
0x0000000000001000

0x0000000000002000
0x0000000022222000
0x0000000000001000

0x0000000000003000
0x0000000033333000
0x0000000000001000

The output should be

0x0000000000000000
0x0000000000000000
0x0000000000001000

0x0000000000001000
0x1111111111111000
0x0000000000001000

0x0000000000002000
0x2222222222222000
0x0000000000001000

0x0000000000003000
0x3333333333333000
0x0000000000001000

As you can see, the upper 32 bits have been chopped off.

Now I need to find an alternative.

You are currently subscribed to ntfsd as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com

2

Strange that NTFS works with such a bug.

----- Original Message -----
From:
To: “File Systems Developers”
Sent: Friday, January 11, 2002 3:22 PM
Subject: [ntfsd] Bug in the FSRTL library

> I found the following bug in the RTL. I thought I would post to save
> someone else the grief that I went through finding it. This bug is
> present in NT4 and W2k. I have not tested it in XP, but i would be
> surprised if it is not there also.
>
> The FsRtl LargeMcb functions don’t utilize the upper 32 bits of the LBN.
> They are totally ignored as if they were 0. Here is code that demonstrates
> the problem:
>
> LARGE_MCB mcb;
> FsRtlInitializeLargeMcb (&mcb, PagedPool);
>
> FsRtlAddLargeMcbEntry (&mcb, 0, 0, 0x1000);
> FsRtlAddLargeMcbEntry (&mcb, 0x1000, 0x1111111111111000, 0x1000);
> FsRtlAddLargeMcbEntry (&mcb, 0x2000, 0x2222222222222000, 0x1000);
> FsRtlAddLargeMcbEntry (&mcb, 0x3000, 0x3333333333333000, 0x1000);
>
> LONGLONG vbo, lbo, size;
> for (int i = 0; FsRtlGetNextLargeMcbEntry (&mcb, i, &vbo, &lbo, &size);
> i++)
> {
> DbgPrintLongLong (vbo);
> DbgPrintLongLong (lbo);
> DbgPrintLongLong (size);
> }
>
> The output from this is:
> 0x0000000000000000
> 0x0000000000000000
> 0x0000000000001000
>
> 0x0000000000001000
> 0x0000000011111000
> 0x0000000000001000
>
> 0x0000000000002000
> 0x0000000022222000
> 0x0000000000001000
>
> 0x0000000000003000
> 0x0000000033333000
> 0x0000000000001000
>
> The output should be
>
> 0x0000000000000000
> 0x0000000000000000
> 0x0000000000001000
>
> 0x0000000000001000
> 0x1111111111111000
> 0x0000000000001000
>
> 0x0000000000002000
> 0x2222222222222000
> 0x0000000000001000
>
> 0x0000000000003000
> 0x3333333333333000
> 0x0000000000001000
>
> As you can see, the upper 32 bits have been chopped off.
>
> Now I need to find an alternative.
>
> —
> You are currently subscribed to ntfsd as: xxxxx@storagecraft.com
> To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com
>

—
You are currently subscribed to ntfsd as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com

3

Have you tried this.

LONGLONG x = (LONGLONG) 0x1111111111111000;

And then call the FsRtlAddLargeMcbEntry functions…

-----Original Message-----
From: Maxim S. Shatskih [mailto:xxxxx@storagecraft.com]
Sent: Friday, January 11, 2002 4:03 PM
To: File Systems Developers
Subject: [ntfsd] Re: Bug in the FSRTL library

Strange that NTFS works with such a bug.

----- Original Message -----
From:
To: “File Systems Developers”
Sent: Friday, January 11, 2002 3:22 PM
Subject: [ntfsd] Bug in the FSRTL library

> I found the following bug in the RTL. I thought I would post to save
> someone else the grief that I went through finding it. This bug is
> present in NT4 and W2k. I have not tested it in XP, but i would be
> surprised if it is not there also.
>
> The FsRtl LargeMcb functions don’t utilize the upper 32 bits of the
> LBN.
> They are totally ignored as if they were 0. Here is code that demonstrates

> the problem:
>
> LARGE_MCB mcb;
> FsRtlInitializeLargeMcb (&mcb, PagedPool);
>
> FsRtlAddLargeMcbEntry (&mcb, 0, 0, 0x1000); FsRtlAddLargeMcbEntry
> (&mcb, 0x1000, 0x1111111111111000, 0x1000); FsRtlAddLargeMcbEntry
> (&mcb, 0x2000, 0x2222222222222000, 0x1000); FsRtlAddLargeMcbEntry
> (&mcb, 0x3000, 0x3333333333333000, 0x1000);
>
> LONGLONG vbo, lbo, size;
> for (int i = 0; FsRtlGetNextLargeMcbEntry (&mcb, i, &vbo, &lbo,
> &size);
> i++)
> {
> DbgPrintLongLong (vbo);
> DbgPrintLongLong (lbo);
> DbgPrintLongLong (size);
> }
>
> The output from this is:
> 0x0000000000000000
> 0x0000000000000000
> 0x0000000000001000
>
> 0x0000000000001000
> 0x0000000011111000
> 0x0000000000001000
>
> 0x0000000000002000
> 0x0000000022222000
> 0x0000000000001000
>
> 0x0000000000003000
> 0x0000000033333000
> 0x0000000000001000
>
> The output should be
>
> 0x0000000000000000
> 0x0000000000000000
> 0x0000000000001000
>
> 0x0000000000001000
> 0x1111111111111000
> 0x0000000000001000
>
> 0x0000000000002000
> 0x2222222222222000
> 0x0000000000001000
>
> 0x0000000000003000
> 0x3333333333333000
> 0x0000000000001000
>
> As you can see, the upper 32 bits have been chopped off.
>
> Now I need to find an alternative.
>
> —
> You are currently subscribed to ntfsd as: xxxxx@storagecraft.com To
> unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com
>

—
You are currently subscribed to ntfsd as: xxxxx@osr.com
To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com

—
You are currently subscribed to ntfsd as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com

4

My original code used actual LONGLONG variables in exactly the way you
describe. I even verified that the variables were correct using SoftICE
just before and after each call.

The code that I published was just a simple little test program that I
wrote to verify the problem.

The bug would never actually show up in NTFS unless you had more than 2^32
sectors on a disk. Using 512 byte sectors, this is a 2 Terabyte file
system. Using 4096 byte sectors, it is a 16 Terabyte file system.

I think this is why it doesn’t show up.

It looks to me like the LargeMCB calls are exactly the same as the normal
MCB calls, they just use LONGLONG arguments.

You are currently subscribed to ntfsd as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com

5

This is a well known attribute of the MCB package; I’m sorry if it
wasn’t properly called out in the documentation that exists for it.

The idea way back in the early days of the system was most likely to
create a call-compatible API which would let it be transparently updated
to a full 64bit integer when it was needed, but using cluster numbers
instead of byte offsets became normal practice and saved 9 bits,
minimum, making it at least a 41bit API. At that point doubling the
MCB’s memory footprint to go from 32 to 64bits lost much of its
motivation.

There are ways to finesse around this.

–
This posting is provided “AS IS” with no warranties, and confers no
rights. You assume all risk for your use.

-----Original Message-----
From: xxxxx@pinnaclesys.com [mailto:xxxxx@pinnaclesys.com]
Sent: Friday, January 11, 2002 7:23 AM
To: File Systems Developers
Subject: [ntfsd] Bug in the FSRTL library

I found the following bug in the RTL. I thought I would post to save
someone else the grief that I went through finding it. This bug is
present in NT4 and W2k. I have not tested it in XP, but i would be
surprised if it is not there also.

The FsRtl LargeMcb functions don’t utilize the upper 32 bits of the LBN.

They are totally ignored as if they were 0. Here is code that
demonstrates
the problem:

LARGE_MCB mcb;
FsRtlInitializeLargeMcb (&mcb, PagedPool);

FsRtlAddLargeMcbEntry (&mcb, 0, 0, 0x1000);
FsRtlAddLargeMcbEntry (&mcb, 0x1000, 0x1111111111111000, 0x1000);
FsRtlAddLargeMcbEntry (&mcb, 0x2000, 0x2222222222222000, 0x1000);
FsRtlAddLargeMcbEntry (&mcb, 0x3000, 0x3333333333333000, 0x1000);

LONGLONG vbo, lbo, size;
for (int i = 0; FsRtlGetNextLargeMcbEntry (&mcb, i, &vbo, &lbo, &size);
i++)
{
DbgPrintLongLong (vbo);
DbgPrintLongLong (lbo);
DbgPrintLongLong (size);
}

The output from this is:
0x0000000000000000
0x0000000000000000
0x0000000000001000

0x0000000000001000
0x0000000011111000
0x0000000000001000

0x0000000000002000
0x0000000022222000
0x0000000000001000

0x0000000000003000
0x0000000033333000
0x0000000000001000

The output should be

0x0000000000000000
0x0000000000000000
0x0000000000001000

0x0000000000001000
0x1111111111111000
0x0000000000001000

0x0000000000002000
0x2222222222222000
0x0000000000001000

0x0000000000003000
0x3333333333333000
0x0000000000001000

As you can see, the upper 32 bits have been chopped off.

Now I need to find an alternative.

You are currently subscribed to ntfsd as: xxxxx@windows.microsoft.com
To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com

You are currently subscribed to ntfsd as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com

6

NTFS has been using an extended form of the MCB package for several
major releases of the OS. The properties of the MCBs are well known
internally - its just a tool, and one which is extensively used - and
are completely intentional if not fully documented yet.

Yes, that’s the major difference between the “small” and “large” mcb
calls - the width of the argument. The small calls are shims over large
calls and pretty much just zero extend the arguments. As I mentioned
earlier, the large calls were intended as a staging up to a full 64bit
MCB package but it stalled “halfway” when the need did not arrive.

–
This posting is provided “AS IS” with no warranties, and confers no
rights. You assume all risk for your use.

-----Original Message-----
From: xxxxx@pinnaclesys.com [mailto:xxxxx@pinnaclesys.com]
Sent: Thursday, January 10, 2002 5:00 PM
To: File Systems Developers
Subject: [ntfsd] Re: Bug in the FSRTL library

My original code used actual LONGLONG variables in exactly the way you
describe. I even verified that the variables were correct using SoftICE
just before and after each call.

The code that I published was just a simple little test program that I
wrote to verify the problem.

The bug would never actually show up in NTFS unless you had more than
2^32
sectors on a disk. Using 512 byte sectors, this is a 2 Terabyte file
system. Using 4096 byte sectors, it is a 16 Terabyte file system.

I think this is why it doesn’t show up.

It looks to me like the LargeMCB calls are exactly the same as the
normal
MCB calls, they just use LONGLONG arguments.

You are currently subscribed to ntfsd as: xxxxx@windows.microsoft.com
To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com

You are currently subscribed to ntfsd as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com