Windows Kernel BUG

Hello all,

I recently discovered that current Windows XP SP2 and Windows Vista
kernels have the following bug:

  • assume we have a driver that opens a file using the DesiredAccess =
    GENERIC_ALL (or almost any combination of flags)
    and ShareAccess = combination of SHARE_READ, WRITE or DELETE.
  • the create file succeeds, as any other io operation on it.
  • while the file is opened by the driver, take an ordinary application
    (notepad.exe) and try to open the file -> SHARING VIOLATION
  • close the file from the driver and the sharing violation is gone.

The guys at Microsoft replied to my queries with: “You may need to use a
security descriptor when you open the file.”
While I shouldn’t have bothered, I took my time and tested this
“suggestion”. The file was correctly created with the ACLs I specified,
but the sharing violation was still there. Further questions received no
reply from Microsoft.

A member of my team discovered that if we set DesiredAccess =
GENERIC_WRITE, the problem is solved.

It is nice to know that not one of the thousand testers of Windows
(including the developers) has considered this scenario.

Andrei Zlate-Podani

Well a few questions:

  1. Which file systems does this fail on?

  2. Does the same problem happen with a user space application using the
    same parameters as your driver to CreareFile?

  3. Have you verified that notepad has SHARE_READ in its CreateFile?

You are announcing a “kernel bug” but you have not, documented the
environment, identified if this is kernel only problem or a general
problem, and finally haven’t documented if this is cause by Notepad and not
the kernel at all.

For years I was a developer or lead teams and I know that this “report”
would be put in the bottom of the pile since there is not enough data to
determine anything useful.


Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
http://www.windrvr.com
Remove StopSpam from the email to reply

P.S. Did you file a bug report on this? If you really feel this is a
problem, Longhorn Server and Windows Server 2003 SP2 are both in beta and
probably have the bug, and XP/SP3 and Vista/SP1 will be in beta in 2007.

“Andrei Zlate-Podani” wrote in message
news:xxxxx@ntdev…
> Hello all,
>
> I recently discovered that current Windows XP SP2 and Windows Vista
> kernels have the following bug:
>
> - assume we have a driver that opens a file using the DesiredAccess =
> GENERIC_ALL (or almost any combination of flags)
> and ShareAccess = combination of SHARE_READ, WRITE or DELETE.
> - the create file succeeds, as any other io operation on it.
> - while the file is opened by the driver, take an ordinary application
> (notepad.exe) and try to open the file -> SHARING VIOLATION
> - close the file from the driver and the sharing violation is gone.
>
> The guys at Microsoft replied to my queries with: “You may need to use a
> security descriptor when you open the file.”
> While I shouldn’t have bothered, I took my time and tested this
> “suggestion”. The file was correctly created with the ACLs I specified,
> but the sharing violation was still there. Further questions received no
> reply from Microsoft.
>
> A member of my team discovered that if we set DesiredAccess =
> GENERIC_WRITE, the problem is solved.
>
> It is nice to know that not one of the thousand testers of Windows
> (including the developers) has considered this scenario.
>
>
> Andrei Zlate-Podani
>
>
>
>
>
>

Microsoft had the chance to tackle the problem when I contacted them.
Instead, I received an incorrect answer and then not at all.

The notification was for the fellow driver developers that would
experience this issue.

Andrei

PS: It was NTFS

Don Burn wrote:

Well a few questions:

  1. Which file systems does this fail on?

  2. Does the same problem happen with a user space application using the
    same parameters as your driver to CreareFile?

  3. Have you verified that notepad has SHARE_READ in its CreateFile?

You are announcing a “kernel bug” but you have not, documented the
environment, identified if this is kernel only problem or a general
problem, and finally haven’t documented if this is cause by Notepad and not
the kernel at all.

For years I was a developer or lead teams and I know that this “report”
would be put in the bottom of the pile since there is not enough data to
determine anything useful.

His point is still very vaild. It’s hard to say what to make of this
without more information, especially concerning SHARE_READ.

mm

>> xxxxx@bitdefender.com 2006-12-21 10:19 >>>
Microsoft had the chance to tackle the problem when I contacted them.
Instead, I received an incorrect answer and then not at all.

The notification was for the fellow driver developers that would
experience this issue.

Andrei

PS: It was NTFS

Don Burn wrote:

Well a few questions:

  1. Which file systems does this fail on?

  2. Does the same problem happen with a user space application using
    the
    same parameters as your driver to CreareFile?

  3. Have you verified that notepad has SHARE_READ in its CreateFile?

You are announcing a “kernel bug” but you have not, documented the
environment, identified if this is kernel only problem or a general
problem, and finally haven’t documented if this is cause by Notepad
and not
the kernel at all.

For years I was a developer or lead teams and I know that this
“report”
would be put in the bottom of the pile since there is not enough data
to
determine anything useful.


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

I had the impression that if you opened a file with FILE_SHARE_DELETE, the
file cannot be opened again unless FILE_SHARE_DELETE is also specified.

“Andrei Zlate-Podani” wrote in message
news:xxxxx@ntdev…
> Hello all,
>
> I recently discovered that current Windows XP SP2 and Windows Vista
> kernels have the following bug:
>
> - assume we have a driver that opens a file using the DesiredAccess =
> GENERIC_ALL (or almost any combination of flags)
> and ShareAccess = combination of SHARE_READ, WRITE or DELETE.
> - the create file succeeds, as any other io operation on it.
> - while the file is opened by the driver, take an ordinary application
> (notepad.exe) and try to open the file -> SHARING VIOLATION
> - close the file from the driver and the sharing violation is gone.
>
> The guys at Microsoft replied to my queries with: “You may need to use a
> security descriptor when you open the file.”
> While I shouldn’t have bothered, I took my time and tested this
> “suggestion”. The file was correctly created with the ACLs I specified,
> but the sharing violation was still there. Further questions received no
> reply from Microsoft.
>
> A member of my team discovered that if we set DesiredAccess =
> GENERIC_WRITE, the problem is solved.
>
> It is nice to know that not one of the thousand testers of Windows
> (including the developers) has considered this scenario.
>
>
> Andrei Zlate-Podani
>
>
>
>
>
>

If you open the file with an app that you write that specifies exactly
the same sharing it will work. It’s not necessarily advised, but it will
work.

Notepad doesn’t happen to open files with
SHARE_READ|SHARE_WRITE|SHARE_DELETE. It therefore is trying to open the
file with exclusive access, which fails… uh, as documented.

Imagine that, an app not designed to share access to a file doesn’t open
it that way.

In fact, almost no applications are designed that way…

Andrei Zlate-Podani wrote:

Hello all,

I recently discovered that current Windows XP SP2 and Windows Vista
kernels have the following bug:

  • assume we have a driver that opens a file using the DesiredAccess =
    GENERIC_ALL (or almost any combination of flags)
    and ShareAccess = combination of SHARE_READ, WRITE or DELETE.
  • the create file succeeds, as any other io operation on it.
  • while the file is opened by the driver, take an ordinary application
    (notepad.exe) and try to open the file -> SHARING VIOLATION
  • close the file from the driver and the sharing violation is gone.

The guys at Microsoft replied to my queries with: “You may need to use a
security descriptor when you open the file.”
While I shouldn’t have bothered, I took my time and tested this
“suggestion”. The file was correctly created with the ACLs I specified,
but the sharing violation was still there. Further questions received no
reply from Microsoft.

A member of my team discovered that if we set DesiredAccess =
GENERIC_WRITE, the problem is solved.

It is nice to know that not one of the thousand testers of Windows
(including the developers) has considered this scenario.

Andrei Zlate-Podani


Ray
(If you want to reply to me off list, please remove “spamblock.” from my
email address)