Change the Irp->UserBuffer.

OSR_Community_User · October 16, 2001, 3:31pm

Hi people,

Can I Change the Irp->UserBuffer to modify the IRP result?

My problem:

I’m writing a Filter Driver with Hide Files capability.
In the completion routine I got the UserBuffer with the list of Files,
but when I change the Irp->UserBuffer to new Buffer with just the
visibles Files, the result is not that I want, all files are showed with
the dir command.

Is this Buffer what should I change?
If True,
Can I release this pointer
e.g. ExFreePool(Irp->UserBuffer);
And Assign new Buffer?
Irp->UserBuffer = NewBufferWithoutSomeFiles;

That is exactly what I’m doing, but don’t work.

Thanks a lot.

Moises.

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

OSR_Community_User · October 16, 2001, 9:06pm

Almost everything you wanted to do below is wrong.
You can’t substitute the UserBuffer field with what you want & complete
the IRP. The UserBuffer - as the name indicate’s - is the user’s buffer.
Regardless of what you substitute, the user will access the buffer that
he initiated the i/o with, & the buffer you substitute (which I presume
you allocated from the system pool incorrectly, will simply be leaked).

Secondly the UserBuffer can be a user-mode virtual address. You can’t
‘free’ it to the system pool.

The solution in your case is - to fill the UserBuffer (not the pointer,
the contents) with your contents.
Ravi

-----Original Message-----
From: Moises Herrera Vazquez [mailto:xxxxx@fie.uclv.edu.cu]
Sent: Tuesday, October 16, 2001 11:58 AM
To: File Systems Developers
Subject: [ntfsd] Change the Irp->UserBuffer.

Hi people,

Can I Change the Irp->UserBuffer to modify the IRP result?

My problem:

I’m writing a Filter Driver with Hide Files capability.
In the completion routine I got the UserBuffer with the list of Files,
but when I change the Irp->UserBuffer to new Buffer with just the
visibles Files, the result is not that I want, all files are showed with
the dir command.

Is this Buffer what should I change?
If True,
Can I release this pointer
e.g. ExFreePool(Irp->UserBuffer);
And Assign new Buffer?
Irp->UserBuffer = NewBufferWithoutSomeFiles;

That is exactly what I’m doing, but don’t work.

Thanks a lot.

Moises.

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

OSR_Community_User · October 17, 2001, 4:56am

>Can I release this pointer

e.g. ExFreePool(Irp->UserBuffer);

Surely no. It is not a kernel pool allocation, but some user space pointer.
Patch the data directly in UserBuffer under __try/__catch.

Max

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

OSR_Community_User · October 17, 2001, 5:14am

Try/Except is needless. If the address is invalid it will BugCheck anyway,
if it’s not no need for Try/Except (unless there’s a code bug, of course:-)

Regards, Dejan.

“Maxim S. Shatskih” wrote:

>Can I release this pointer
>e.g. ExFreePool(Irp->UserBuffer);

Surely no. It is not a kernel pool allocation, but some user space pointer.
Patch the data directly in UserBuffer under __try/__catch.

Max

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

–
Kind regards, Dejan M. CEO Alfa Co. www.alfasp.com
E-mail: xxxxx@alfasp.com
ICQ#: 56570367
Alfa File Monitor - File monitoring system for Win32 developers.
Alfa File Protector - File protection and hiding system for Win32 developers.

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

OSR_Community_User · October 17, 2001, 8:53am

This is wrong.

If you’re accessing a user buffer directly, you must protect that access
with _try/_except. Also, you must successfully call ProbeForRead or
ProbeForWrite inside try/_except before accessing the buffer. If you
follow these steps, the system will not blue screen when you try to
access an invalid pointer.

-----Original Message-----
From: Dejan Maksimovic [mailto:xxxxx@alfasp.com]
Sent: Wednesday, October 17, 2001 4:10 AM
To: File Systems Developers
Subject: [ntfsd] Re: Change the Irp->UserBuffer.

Try/Except is needless. If the address is invalid it will
BugCheck anyway,
if it’s not no need for Try/Except (unless there’s a code
bug, of course:-)

Regards, Dejan.

“Maxim S. Shatskih” wrote:

> >Can I release this pointer
> >e.g. ExFreePool(Irp->UserBuffer);
>
> Surely no. It is not a kernel pool allocation, but some
user space pointer.
> Patch the data directly in UserBuffer under __try/__catch.
>
> Max
>
> —
> You are currently subscribed to ntfsd as: xxxxx@alfasp.com
> To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com

–
Kind regards, Dejan M. CEO Alfa Co. www.alfasp.com
E-mail: xxxxx@alfasp.com
ICQ#: 56570367
Alfa File Monitor - File monitoring system for Win32 developers.
Alfa File Protector - File protection and hiding system for
Win32 developers.

You are currently subscribed to ntfsd as: xxxxx@nsisoftware.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

OSR_Community_User · October 17, 2001, 10:22am

For Probe, yes.
But, for the purpose of filtering directory entries, one would not
access the buffer before it is filled by the file system, and only if the
call was successful.
Thus, the buffer won’t be touched unless it is valid.
BTW, the ProbeForRead that I saw in the headers doesn’t really check the
validity of the address, rather it just checks the alignment. Am I missing
something?

Regards, Dejan.

Rob Fuller wrote:

This is wrong.

If you’re accessing a user buffer directly, you must protect that access
with _try/_except. Also, you must successfully call ProbeForRead or
ProbeForWrite inside try/_except before accessing the buffer. If you
follow these steps, the system will not blue screen when you try to
access an invalid pointer.

> -----Original Message-----
> From: Dejan Maksimovic [mailto:xxxxx@alfasp.com]
> Sent: Wednesday, October 17, 2001 4:10 AM
> To: File Systems Developers
> Subject: [ntfsd] Re: Change the Irp->UserBuffer.
>
>
>
> Try/Except is needless. If the address is invalid it will
> BugCheck anyway,
> if it’s not no need for Try/Except (unless there’s a code
> bug, of course:-)
>
> Regards, Dejan.
>
> “Maxim S. Shatskih” wrote:
>
> > >Can I release this pointer
> > >e.g. ExFreePool(Irp->UserBuffer);
> >
> > Surely no. It is not a kernel pool allocation, but some
> user space pointer.
> > Patch the data directly in UserBuffer under __try/__catch.
> >
> > Max
> >
> > —
> > You are currently subscribed to ntfsd as: xxxxx@alfasp.com
> > To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com
>
> –
> Kind regards, Dejan M. CEO Alfa Co. www.alfasp.com
> E-mail: xxxxx@alfasp.com
> ICQ#: 56570367
> Alfa File Monitor - File monitoring system for Win32 developers.
> Alfa File Protector - File protection and hiding system for
> Win32 developers.
>
>
>
> —
> You are currently subscribed to ntfsd as: xxxxx@nsisoftware.com
> To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com
>

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

–
Kind regards, Dejan M. CEO Alfa Co. www.alfasp.com
E-mail: xxxxx@alfasp.com
ICQ#: 56570367
Alfa File Monitor - File monitoring system for Win32 developers.
Alfa File Protector - File protection and hiding system for Win32
developers.

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

OSR_Community_User · October 17, 2001, 10:50am

> From: Dejan Maksimovic [mailto:xxxxx@alfasp.com]

For Probe, yes.
But, for the purpose of filtering directory entries, one would not
access the buffer before it is filled by the file system, and
only if the
call was successful.
Thus, the buffer won’t be touched unless it is valid.

There is a race here. The caller’s process could make that buffer
invalid between the file system accessing the user’s buffer and you
touching it. Thus, you should always protect access to the buffer.
Paranoia is the key to writing robust kernel code.

BTW, the ProbeForRead that I saw in the headers doesn’t
really check the
validity of the address, rather it just checks the alignment.
Am I missing
something?

Yes. Notice that it checks to make sure the address is a user-mode
address. That is the comparison against MM_USER_PROBE_ADDRESS. This
prevents blue screens such as PAGE_FAULT_IN_NONPAGED_AREA when you try
to access the buffer inside your _try/_except construct. The
_try/_except will catch the attempt to use an invalid user pointer.
ProbeForRead is responsible for catching the errors that _try/_except
cannot.

Rob Fuller wrote:

> This is wrong.
>
> If you’re accessing a user buffer directly, you must
protect that access
> with _try/_except. Also, you must successfully call ProbeForRead or
> ProbeForWrite inside try/_except before accessing the
buffer. If you
> follow these steps, the system will not blue screen when you try to
> access an invalid pointer.
>
> > -----Original Message-----
> > From: Dejan Maksimovic [mailto:xxxxx@alfasp.com]
> > Sent: Wednesday, October 17, 2001 4:10 AM
> > To: File Systems Developers
> > Subject: [ntfsd] Re: Change the Irp->UserBuffer.
> >
> >
> >
> > Try/Except is needless. If the address is invalid it will
> > BugCheck anyway,
> > if it’s not no need for Try/Except (unless there’s a code
> > bug, of course:-)
> >
> > Regards, Dejan.
> >
> > “Maxim S. Shatskih” wrote:
> >
> > > >Can I release this pointer
> > > >e.g. ExFreePool(Irp->UserBuffer);
> > >
> > > Surely no. It is not a kernel pool allocation, but some
> > user space pointer.
> > > Patch the data directly in UserBuffer under __try/__catch.
> > >
> > > Max
> > >
> > > —
> > > You are currently subscribed to ntfsd as: xxxxx@alfasp.com
> > > To unsubscribe send a blank email to
leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com
> >
> > –
> > Kind regards, Dejan M. CEO Alfa Co. www.alfasp.com
> > E-mail: xxxxx@alfasp.com
> > ICQ#: 56570367
> > Alfa File Monitor - File monitoring system for Win32 developers.
> > Alfa File Protector - File protection and hiding system for
> > Win32 developers.
> >
> >
> >
> > —
> > You are currently subscribed to ntfsd as: xxxxx@nsisoftware.com
> > To unsubscribe send a blank email to
leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com
> >
>
> —
> You are currently subscribed to ntfsd as: xxxxx@alfasp.com
> To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com

–
Kind regards, Dejan M. CEO Alfa Co. www.alfasp.com
E-mail: xxxxx@alfasp.com
ICQ#: 56570367
Alfa File Monitor - File monitoring system for Win32 developers.
Alfa File Protector - File protection and hiding system for Win32
developers.

You are currently subscribed to ntfsd as: xxxxx@nsisoftware.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

OSR_Community_User · October 17, 2001, 2:43pm

Rob is correct about the race condition. Never, never assume anything
from userland is valid. As sure as you do, well, we know what’ll happen.

-----Original Message-----
From: Rob Fuller
Sent: Wednesday, October 17, 2001 9:47 AM
To: File Systems Developers
Subject: [ntfsd] Re: Change the Irp->UserBuffer.

From: Dejan Maksimovic [mailto:xxxxx@alfasp.com]

For Probe, yes.
But, for the purpose of filtering directory entries, one would not
access the buffer before it is filled by the file system, and
only if the
call was successful.
Thus, the buffer won’t be touched unless it is valid.

There is a race here. The caller’s process could make that buffer
invalid between the file system accessing the user’s buffer and you
touching it. Thus, you should always protect access to the buffer.
Paranoia is the key to writing robust kernel code.

BTW, the ProbeForRead that I saw in the headers doesn’t
really check the
validity of the address, rather it just checks the alignment.
Am I missing
something?

Yes. Notice that it checks to make sure the address is a user-mode
address. That is the comparison against MM_USER_PROBE_ADDRESS. This
prevents blue screens such as PAGE_FAULT_IN_NONPAGED_AREA when you try
to access the buffer inside your _try/_except construct. The
_try/_except will catch the attempt to use an invalid user pointer.
ProbeForRead is responsible for catching the errors that _try/_except
cannot.

Rob Fuller wrote:

> This is wrong.
>
> If you’re accessing a user buffer directly, you must
protect that access
> with _try/_except. Also, you must successfully call ProbeForRead or
> ProbeForWrite inside try/_except before accessing the
buffer. If you
> follow these steps, the system will not blue screen when you try to
> access an invalid pointer.
>
> > -----Original Message-----
> > From: Dejan Maksimovic [mailto:xxxxx@alfasp.com]
> > Sent: Wednesday, October 17, 2001 4:10 AM
> > To: File Systems Developers
> > Subject: [ntfsd] Re: Change the Irp->UserBuffer.
> >
> >
> >
> > Try/Except is needless. If the address is invalid it will
> > BugCheck anyway,
> > if it’s not no need for Try/Except (unless there’s a code
> > bug, of course:-)
> >
> > Regards, Dejan.
> >
> > “Maxim S. Shatskih” wrote:
> >
> > > >Can I release this pointer
> > > >e.g. ExFreePool(Irp->UserBuffer);
> > >
> > > Surely no. It is not a kernel pool allocation, but some
> > user space pointer.
> > > Patch the data directly in UserBuffer under __try/__catch.
> > >
> > > Max
> > >
> > > —
> > > You are currently subscribed to ntfsd as: xxxxx@alfasp.com
> > > To unsubscribe send a blank email to
leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com
> >
> > –
> > Kind regards, Dejan M. CEO Alfa Co. www.alfasp.com
> > E-mail: xxxxx@alfasp.com
> > ICQ#: 56570367
> > Alfa File Monitor - File monitoring system for Win32 developers.
> > Alfa File Protector - File protection and hiding system for
> > Win32 developers.
> >
> >
> >
> > —
> > You are currently subscribed to ntfsd as: xxxxx@nsisoftware.com
> > To unsubscribe send a blank email to
leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com
> >
>
> —
> You are currently subscribed to ntfsd as: xxxxx@alfasp.com
> To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com

–
Kind regards, Dejan M. CEO Alfa Co. www.alfasp.com
E-mail: xxxxx@alfasp.com
ICQ#: 56570367
Alfa File Monitor - File monitoring system for Win32 developers.
Alfa File Protector - File protection and hiding system for Win32
developers.

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

You are currently subscribed to ntfsd as: xxxxx@nsisoftware.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

OSR_Community_User · October 17, 2001, 2:56pm

> > For Probe, yes.

> But, for the purpose of filtering directory entries, one would not
> access the buffer before it is filled by the file system, and
> only if the
> call was successful.
> Thus, the buffer won’t be touched unless it is valid.

There is a race here. The caller’s process could make that buffer
invalid between the file system accessing the user’s buffer and you
touching it. Thus, you should always protect access to the buffer.
Paranoia is the key to writing robust kernel code.

The caller needs the buffer to be valid after the filter processes it,
so making it invalid during a call would make it invalid after the call - or
make the unwanted results.
If the user is John-Doe-Brainless, paranoia is not enough. If he wants
to crash the system he doesn’t need weakness in a 3rd party driver, you
know:-)

> BTW, the ProbeForRead that I saw in the headers doesn’t
> really check the
> validity of the address, rather it just checks the alignment.
> Am I missing
> something?

Yes. Notice that it checks to make sure the address is a user-mode
address. That is the comparison against MM_USER_PROBE_ADDRESS. This
prevents blue screens such as PAGE_FAULT_IN_NONPAGED_AREA when you try to
access the buffer inside your _try/_except construct. The
_try/_except will catch the attempt to use an invalid user pointer.
ProbeForRead is responsible for catching the errors that _try/_except
cannot.

Interesting. I thought trying to touch invalid user mode address would
also give PAGE_FAULT_IN_NON_PAGED_AREA bsod.

–
Kind regards, Dejan M. CEO Alfa Co. www.alfasp.com
E-mail: xxxxx@alfasp.com
ICQ#: 56570367
Alfa File Monitor - File monitoring system for Win32 developers.
Alfa File Protector - File protection and hiding system for Win32
developers.

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

OSR_Community_User · October 17, 2001, 3:47pm

There are many reasons an application buffer might become invalid that have
nothing to do with malicious intent, or even stupidity.

For example, an application might be using some form of exception handling.
An innocent enough piece of code uses a stack-based buffer; the thread is
then thrown an exception which it traps, but of course it also unwinds its
stack. NOW the buffer contents change.

Or perhaps the process terminates and its address space is torn down. The
region of the addresses for the buffer are no longer valid.

There are many things that can go wrong in an application that can result in
this behavior. Rob is absolutely right that one must be cautious when
accessing any user buffer within a kernel driver.

Regards,

Tony

Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com

See the new NTFSD FAQ on the OSR Web Site!

-----Original Message-----
From: Dejan Maksimovic [mailto:xxxxx@alfasp.com]
Sent: Wednesday, October 17, 2001 2:53 PM
To: File Systems Developers
Subject: [ntfsd] Re: Change the Irp->UserBuffer.

> For Probe, yes.
> But, for the purpose of filtering directory entries, one would not
> access the buffer before it is filled by the file system, and
> only if the
> call was successful.
> Thus, the buffer won’t be touched unless it is valid.

There is a race here. The caller’s process could make that buffer
invalid between the file system accessing the user’s buffer and you
touching it. Thus, you should always protect access to the buffer.
Paranoia is the key to writing robust kernel code.

The caller needs the buffer to be valid after the filter processes it,
so making it invalid during a call would make it invalid after the call - or
make the unwanted results.
If the user is John-Doe-Brainless, paranoia is not enough. If he wants
to crash the system he doesn’t need weakness in a 3rd party driver, you
know:-)

> BTW, the ProbeForRead that I saw in the headers doesn’t
> really check the
> validity of the address, rather it just checks the alignment.
> Am I missing
> something?

Yes. Notice that it checks to make sure the address is a user-mode
address. That is the comparison against MM_USER_PROBE_ADDRESS. This
prevents blue screens such as PAGE_FAULT_IN_NONPAGED_AREA when you try to
access the buffer inside your _try/_except construct. The
_try/_except will catch the attempt to use an invalid user pointer.
ProbeForRead is responsible for catching the errors that _try/_except
cannot.

Interesting. I thought trying to touch invalid user mode address would
also give PAGE_FAULT_IN_NON_PAGED_AREA bsod.

–
Kind regards, Dejan M. CEO Alfa Co. www.alfasp.com
E-mail: xxxxx@alfasp.com
ICQ#: 56570367
Alfa File Monitor - File monitoring system for Win32 developers.
Alfa File Protector - File protection and hiding system for Win32
developers.

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