STATUS_INVALID_NETWORK_RESPONSE returned from IRP_MJ_QUERY_SECURITY

NTFSD
1

I was hoping the vast knowledge of FSD experts could help me out with this one! I have an interop problem relating to handling IRP_MJ_QUERY_SECURITY over a CIFS share.

Using Procmon on the Server (ie. my FSD), I see a STATUS_BUFFER_OVERFLOW, followed by a STATUS_SUCCESS. Using Procmon on the Clients, I see a STATUS_BUFFER_OVERFLOW followed by a STATUS_INVALID_NETWORK_RESPONSE. So somewhere that success is being converted into an invalid network response.

W2K3 and Windows 7 clients to W2K3 servers always fail.
W2K3 clients to W2K8 R2 servers always fail.
Windows 7 clients to W2K8 R2 servers actually succeed.

I saw a post on some forum referencing a security fix and how STATUS_INVALID_NETWORK_RESPONSE could be returned if the network redirector deems the SD structure
http://www.microsoft.com/technet/security/bulletin/MS10-020.mspx?pubDate=2010-04-13
Fix described here: http://old.nabble.com/Microsoft-Security-Bulletin-MS10-020-(KB980232)-vs-OpenAFS-td28686529.html

Here is essentially the meaty code for how we handle IRP_MJ_QUERY_SECURITY: (Fcb->pSecDesc holds the self-relative SD.)

RtlZeroMemory(Irp->UserBuffer, IrpSp->Parameters.QuerySecurity.Length);
ULONG ulUserBufferSize = IrpSp->Parameters.QuerySecurity.Length;

Irp->IoStatus.Status = SeQuerySecurityDescriptorInfo(&IrpSp->Parameters.QuerySecurity.SecurityInformation, (PSECURITY_DESCRIPTOR) Irp->UserBuffer, &ulUserBufferSize, &Fcb->pSecDesc);

if (Irp->IoStatus.Status == STATUS_BUFFER_TOO_SMALL )
{
IrpSp->Parameters.QuerySecurity.SecurityInformation, Irp->UserBuffer, ulUserBufferSize, IrpSp->Parameters.QuerySecurity.Length, Fcb->FullFileName.Buffer);

Irp->IoStatus.Information = ulUserBufferSize;
Status = STATUS_BUFFER_OVERFLOW;
}

So I’m guessing that something in my SD might be invalid according to the redirector, but I can’t imagine what. Or its something completely different. Anyone else seen this? Thanks!

2

Tracking these down can be annoying. Unfortunately,
STATUS_INVALID_NETWORK_RESPONSE is returned from just about *everywhere* in
redirector, so trying to figure out what exactly it doesn’t like based on
the error code alone is pretty much impossible.

I’ve never had this particular issue, so I can’t point directly at what to
look for. However, I can recommend how I’d approach this and that would be
by using NTFS as my working model. Try comparing the data returned between
your FSD and NTFS for the same query, maybe you can spot the difference
between the two. Looking at Wireshark traces from a working case and a
broken case might also provide some insight.

And two sanity checks on the fragment:

  1. You are doing this in a __try/__except block, right? It’s not your bug,
    but it’s *a* bug if you don’t have it here.

  2. You’re setting the Information field in the success case too, yes?

-scott

–
Scott Noone
Consulting Associate and Chief System Problem Analyst
OSR Open Systems Resources, Inc.
http://www.osronline.com

wrote in message news:xxxxx@ntfsd…

I was hoping the vast knowledge of FSD experts could help me out with this
one! I have an interop problem relating to handling IRP_MJ_QUERY_SECURITY
over a CIFS share.

Using Procmon on the Server (ie. my FSD), I see a STATUS_BUFFER_OVERFLOW,
followed by a STATUS_SUCCESS. Using Procmon on the Clients, I see a
STATUS_BUFFER_OVERFLOW followed by a STATUS_INVALID_NETWORK_RESPONSE. So
somewhere that success is being converted into an invalid network response.

W2K3 and Windows 7 clients to W2K3 servers always fail.
W2K3 clients to W2K8 R2 servers always fail.
Windows 7 clients to W2K8 R2 servers actually succeed.

I saw a post on some forum referencing a security fix and how
STATUS_INVALID_NETWORK_RESPONSE could be returned if the network redirector
deems the SD structure
http://www.microsoft.com/technet/security/bulletin/MS10-020.mspx?pubDate=2010-04-13
Fix described here:
http://old.nabble.com/Microsoft-Security-Bulletin-MS10-020-(KB980232)-vs-OpenAFS-td28686529.html

Here is essentially the meaty code for how we handle IRP_MJ_QUERY_SECURITY:
(Fcb->pSecDesc holds the self-relative SD.)

RtlZeroMemory(Irp->UserBuffer, IrpSp->Parameters.QuerySecurity.Length);
ULONG ulUserBufferSize = IrpSp->Parameters.QuerySecurity.Length;

Irp->IoStatus.Status =
SeQuerySecurityDescriptorInfo(&IrpSp->Parameters.QuerySecurity.SecurityInformation,
(PSECURITY_DESCRIPTOR) Irp->UserBuffer, &ulUserBufferSize, &Fcb->pSecDesc);

if (Irp->IoStatus.Status == STATUS_BUFFER_TOO_SMALL )
{
IrpSp->Parameters.QuerySecurity.SecurityInformation, Irp->UserBuffer,
ulUserBufferSize, IrpSp->Parameters.QuerySecurity.Length,
Fcb->FullFileName.Buffer);

Irp->IoStatus.Information = ulUserBufferSize;
Status = STATUS_BUFFER_OVERFLOW;
}

So I’m guessing that something in my SD might be invalid according to the
redirector, but I can’t imagine what. Or its something completely
different. Anyone else seen this? Thanks!

3
  1. You are doing this in a __try/__except block, right? It’s not your bug, but it’s *a* bug if you don’t have it here.

Definitely. That was just a code fragment.

  1. You’re setting the Information field in the success case too, yes?

BINGO, that was it!!! +1 for a correct answer!

Irp->IoStatus.Information = ulUserBufferSize; // Return size of the SD info generated.

I think its funny that it worked between SMB2 client/server. It was not evident (to me anyway) from the MSDN documentation that is what I had to do. I also searched OSR’s articles and didn’t find one directly relevant. Handling SDs has been a thorn in my side for years now, although MSDN is getting better with the docs. Although, I suppose if a parameter is in & out, its there for a reason.

Thank you very much!

4

Nice! I can theorize why it might have worked sometimes, but as long as that
fixed it who cares :slight_smile:

It was not evident (to me anyway) from the MSDN documentation that is what
I had to do.

This is the downside to only have FAT source as an example to work from. It
works great until, you know, you want to support something that FAT doesn’t.
Glad it ended up being an easy fix.

-scott

–
Scott Noone
Consulting Associate and Chief System Problem Analyst
OSR Open Systems Resources, Inc.
http://www.osronline.com

wrote in message news:xxxxx@ntfsd…

  1. You are doing this in a __try/__except block, right? It’s not your bug,
    but it’s *a* bug if you don’t have it here.

Definitely. That was just a code fragment.

  1. You’re setting the Information field in the success case too, yes?

BINGO, that was it!!! +1 for a correct answer!

Irp->IoStatus.Information = ulUserBufferSize; // Return size of the SD
info generated.

I think its funny that it worked between SMB2 client/server. It was not
evident (to me anyway) from the MSDN documentation that is what I had to do.
I also searched OSR’s articles and didn’t find one directly relevant.
Handling SDs has been a thorn in my side for years now, although MSDN is
getting better with the docs. Although, I suppose if a parameter is in &
out, its there for a reason.

Thank you very much!