資料竄改對驅動程式是一種威脅，但對文件系統驅動程式和文件系統篩選驅動程式則是嚴重的威脅。 對於所有驅動程式而言，使用者模式元件與內核模式元件之間共用的任何控制結構都有可能會被使用者模式元件修改，此時正值其被內核模式元件使用期間，這可能會形成潛在威脅。 檔系統和篩選驅動程序特別容易受到這種攻擊類別的影響，因為它們強烈依賴METHOD_NEITHER透過其虛擬位址直接存取用戶緩衝區的數據傳輸類型。 快速 I/O 也會直接存取原始的使用者模式緩衝區。 此處的風險是驅動程式可能會在應用程式修改資料時使用此數據。 一般而言，驅動程式會藉由驗證數據來嘗試防止這種情況。 但是，只有當數據在驗證後無法改變時，數據驗證才能正常運作。
針對檔案系統和檔案系統篩選驅動程式，有許多 IOCTL 和 FSCTL 作業可用來在使用者模式應用程式和各種內核模式驅動程式之間傳輸資訊。 此外，這類驅動程式通常會有私人IOCTL和FSCTL作業，這些作業也會在使用者模式服務與其核心模式驅動程式之間傳輸控制和數據資訊。
此設計模型中固有的假設是，只有驅動程式的服務或應用程式會利用其介面。 這類設計和實作有風險，原因如下：
惡意應用程式可以將有效的緩衝區傳送至驅動程式，然後接著修改數據，以嘗試探查並找出驅動程式的弱點。
控制程式應用程式內的失敗可能會導致控件緩衝區的數據內容變成無效。 例如，如果例外狀況變更控制流程並造成堆疊區域重複使用，堆棧型控件區域可能會變成無效。
在實作方面，若要防範此類別的問題，需要持續保持警惕。 緩衝區必須位於非揮發性記憶體中（僅限內核或只讀記憶體），才能進行驗證。 如果緩衝區包含任何其他緩衝區或控件結構的參考，它們也必須位於非揮發性記憶體中，才能進行驗證。
開發人員也應該注意，使用 FastIoDeviceControl 分派的 IOCTL 會將數據傳入原始用戶緩衝區。 因此，實作IOCTL快速I/O版本的驅動程序應該採取適當的步驟來防止問題。
請注意，驗證數據本身是不夠的。 例如，成功呼叫 ProbeForWrite 可能表示緩衝區有效，但應用程式地址空間中的後續變更可能會導致該狀態變更。 例如，在驅動程序實際使用緩衝區之前，應用程式可能會終止。 因此，驅動程式必須防止應用程式位址空間內的任何變更。 一般而言，這是透過在任何直接存取用戶緩衝區位址的程式代碼周圍使用結構化例外狀況處理，即搭配使用 `__try` 和 `__except` 來完成的。