![[H]ard|Forum](/styles/hardforum/xenforo/logo_dark.png){kind=logo}
![Zarathustra[H]](https://cdn.hardforum.com/data/avatars/m/9/9298.jpg?1677728934){kind=avatar}
Zarathustra[H]
Extremely [H]
- Joined
- Oct 29, 2000
- Messages
- 37,460
Russian site habrahabr.ru has a story up regarding how a new bug found in NTFS allows malformed filenames to bluescreen Windows 7 and 8.1 boxes. (Those of us not of unusual linguistic inclination can access an English version courtesy of Google Translate.) Apparently this issue is made worse by the fact that malicious websites can embed images using this malformed filename format, causing browsers to save it in their image cache and crash.
If you are somewhat of an old-timer like me, this may sound familiar due to the late 90's C:\con\con bug found in Windows 98.
When an attempt is made to open a file relative to the $ mft file, the NtfsFindStartingNode function will not find it, because This function performs a search somewhat differently, in contrast to the function NtfsOpenSubdirectory, which finds this file always. Therefore, the loop starts from the root of the file system. Next, the function NtfsOpenSubdirectory will open this file and grab it ERESOURCE exclusively. At the next iteration, the loop will find that the file is not a directory, and therefore will interrupt its operation with an error. And at the end of its work function NtfsCommonCreate through the function NtfsTeardownStructures will try to close it. Function NtfsTeardownStructures, in turn, will face the fact that it can not close the file, because It is opened by the file system itself when it is mounted. In this case, contrary to the expectations of the NtfsCommonCreate function, the NtfsTeardownStructures function will not free the ERESOURCE $ mft file. Thus, he will remain captured forever. Therefore, for example, when you try to create a file or read a volume file, the NTFS file system will try to grab the ERESOURCE $ mft file and hang at this stage forever.
If you are somewhat of an old-timer like me, this may sound familiar due to the late 90's C:\con\con bug found in Windows 98.
When an attempt is made to open a file relative to the $ mft file, the NtfsFindStartingNode function will not find it, because This function performs a search somewhat differently, in contrast to the function NtfsOpenSubdirectory, which finds this file always. Therefore, the loop starts from the root of the file system. Next, the function NtfsOpenSubdirectory will open this file and grab it ERESOURCE exclusively. At the next iteration, the loop will find that the file is not a directory, and therefore will interrupt its operation with an error. And at the end of its work function NtfsCommonCreate through the function NtfsTeardownStructures will try to close it. Function NtfsTeardownStructures, in turn, will face the fact that it can not close the file, because It is opened by the file system itself when it is mounted. In this case, contrary to the expectations of the NtfsCommonCreate function, the NtfsTeardownStructures function will not free the ERESOURCE $ mft file. Thus, he will remain captured forever. Therefore, for example, when you try to create a file or read a volume file, the NTFS file system will try to grab the ERESOURCE $ mft file and hang at this stage forever.
