[CDFS] Properly check for legal names in CdIsLegalName()
authorPierre Schweitzer <pierre@reactos.org>
Tue, 28 Aug 2018 05:48:44 +0000 (07:48 +0200)
committerPierre Schweitzer <pierre@reactos.org>
Tue, 28 Aug 2018 05:50:58 +0000 (07:50 +0200)
commit9d0596afe188a45b975b287de74a10401ef6ad4a
tree414c27b7e9d2f3dcec10b02584294e4d11f12354
parentcdb9f03236fe15a46e042900af50efc56b11684a
[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