c - 为什么过早访问 ReadFileEx 的输入缓冲区会导致数据损坏？

Question

ReadFileEx's documentation说:

Accessing the input buffer while a read operation is using the buffer may lead to corruption of the data read into that buffer. Applications must not read from, write to, reallocate, or free the input buffer that a read operation is using until the read operation completes.

这是我第一次听说读取数据导致损坏。
所以我的问题是，为什么会发生这种情况？ 读操作怎么可能导致数据损坏？
导致这种情况的原因是什么？

更新:

我在 ReadFile's page 上注意到一个有趣的句子:

The ReadFile function may fail with ERROR_NOT_ENOUGH_QUOTA, which means the calling process's buffer could not be page-locked.

也许这与答案有关？

Answer 1

我不太确定，所以我很乐意接受评论，但我想:

ReadFileEx 被实现为使用 NtReadFile(或多或少它只是一个薄包装)。 NtReadFile 做了很多事情，但它使用 IoBuildAsynchronousFsdRequest(或 IoBuildSynchronousFsdRequest)来执行它的任务。来自 this article我们知道:

If the target device object is set up do direct i/o (DO_DIRECT_IO), then IoBuildAsynchronousFsdRequest creates an MDL to describe the buffer and locks the pages.

(重点是我的)

然后我猜他们用 IoWriteAccess 调用了 MmProbeAndLockPages，这是由驱动程序在内核模式下完成的，然后用户提供的缓冲区(在用户模式下)甚至不能访问以供阅读。

我不知道如果你这样做会发生什么，可能会抛出 SEH 异常并且你的代码会失败。

编辑
正如在已编辑的问题中指出的那样，即使 ReadFile 函数也禁止用户在操作完成之前从缓冲区读取数据，并且它可能会返回 ERROR_NOT_ENOUGH_QUOTA:

The ReadFile function may fail with ERROR_NOT_ENOUGH_QUOTA, which means the calling process's buffer could not be page-locked.

至少这表明 ReadFile(用户未提供缓冲区)将分配一个页面并锁定它(好的，它有在我链接的文章中也说过......)。仍然需要了解用户定义的缓冲区是否也会发生损坏(如果有的话，我强烈同意@David)(如@Ben 所指出的，页面上的锁定在大多数情况下是不可能的)。

我不认为它使用页面错误来检测缓冲区溢出只是因为它知道调用之前所需的数据量然后它可以分配一次。

那么为什么数据会被破坏？毕竟这里的一切都可能是由于错误而不是数据损坏。这是一个很大的猜测，但有一个关于 MmProbeAndLockPages 的已知问题:

This issue occurs because of a race condition in the Memory Manager. When a driver calls the MmProbeAndLockPages routine, this routine may read some data that is being modified by another thread. Therefore, data corruption occurs. Depending on how the corrupted data is used, the application or the system may crash.

很难说这个问题是否已经在非常低的级别上得到解决，或者如果应用程序做了一些奇怪的事情是否仍然可以利用...