01/01: [CDFS] Properly check for legal names in CdIsLegalName()

[Pierre Schweitzer]

https://git.reactos.org/?p=reactos.git;a=commitdiff;h=9d0596afe188a45b975b2…

commit 9d0596afe188a45b975b287de74a10401ef6ad4a
Author:     Pierre Schweitzer <pierre(a)reactos.org>
AuthorDate: Tue Aug 28 07:48:44 2018 +0200
Commit:     Pierre Schweitzer <pierre(a)reactos.org>
CommitDate: Tue Aug 28 07:50:58 2018 +0200

    [CDFS] Properly check for legal names in CdIsLegalName()
    
    Up to now, it was working by chance. Indeed, due to the invalid
    ASCII check performed before calling FsRtlIsAnsiCharacterLegalHpfs(), the
    macro is improperly called and overruns the FsRtlLegalAnsiCharacterArray
    buffer. Fortunately, up to now, right after that buffer in kernel binary
    there are strings which are more or less consistent with the flags that
    are expected by the macro, causing a decent behavior of
    FsRtlIsAnsiCharacterLegalHpfs() even for extended ASCII characters
    (whereas FsRtlIsAnsiCharacterLegalHpfs() is only designed for ASCII
    characters). But this is a totally out of control and wrong behavior.
    A single change in the way the kernel was built could have caused the
    CDFS driver not to work as previously.
    
    I have made the choice to allow any extended ASCII character as done
    for the unicode characters. This is a good compromise to avoid drastic
    regressions for users having extended ASCII characters in their CD
    file names.
    
    This imports proposed upstream commit 1b6b625641dffb49951e60398e1a9c672318ea71
    See pull request https://github.com/Microsoft/Windows-driver-samples/pull/278
    
    CORE-14067
---
 drivers/filesystems/cdfs/namesup.c | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/drivers/filesystems/cdfs/namesup.c b/drivers/filesystems/cdfs/namesup.c
index 96e3aa3d3e..6f375f56ec 100644
--- a/drivers/filesystems/cdfs/namesup.c
+++ b/drivers/filesystems/cdfs/namesup.c
@@ -410,7 +410,17 @@ Return Value:
          Wchar < Add2Ptr( FileName->Buffer, FileName->Length, PWCHAR );
          Wchar++) {
 
+#ifndef __REACTOS__
         if ((*Wchar < 0xff) &&
+#else
+        //
+        // Check whether ASCII characters are legal.
+        // We will consider the rest of the characters
+        // (extended ASCII and unicode) as legal.
+        //
+
+        if ((*Wchar < 0x80) &&
+#endif
             !FsRtlIsAnsiCharacterLegalHpfs( *Wchar, FALSE ) &&
             (*Wchar != L'"') &&
             (*Wchar != L'<') &&