Freigeben über

Fehler beim Validieren von Objekthandles

Einige Treiber müssen Objekte bearbeiten, die von Aufrufern übergeben werden oder zwei Dateiobjekte gleichzeitig verarbeiten müssen. Beispielsweise kann ein Modemtreiber ein Handle für ein Ereignisobjekt empfangen, oder ein Netzwerktreiber empfängt Handles für zwei verschiedene Dateiobjekte. Der Treiber muss diese Handles überprüfen. Da sie von einem Anrufer und nicht über den E/A-Manager übergeben werden, kann der E/A-Manager keine Überprüfungen durchführen.

Im folgenden Codeausschnitt wurde dem Treiber beispielsweise das Handle AscInfo-AddressHandle> übergeben, aber es wurde nicht validiert, bevor ObReferenceObjectByHandle aufgerufen wurde.

   //
   // This handle is embedded in a buffered request.
   //
   status = ObReferenceObjectByHandle(
                      AscInfo->AddressHandle,
                      0,
                      NULL,
                      KernelMode,
                      &fileObject,
                      NULL);

   if (NT_SUCCESS(status)) {
       if ( (fileObject->DeviceObject == DeviceObject) &&
            (fileObject->FsContext2 == TRANSPORT_SOCK) ) {

Obwohl der Aufruf von ObReferenceObjectByHandle erfolgreich ist, kann der Code nicht sicherstellen, dass der zurückgegebene Zeiger auf ein Dateiobjekt verweist; es vertraut dem Aufrufer, die richtigen Informationen zu übergeben.

Auch wenn alle Parameter für den Aufruf von ObReferenceObjectByHandle korrekt sind und der Aufruf erfolgreich ist, kann ein Treiber weiterhin unerwartete Ergebnisse erhalten, wenn das Dateiobjekt nicht für den Treiber vorgesehen ist. Im folgenden Codefragment geht der Treiber davon aus, dass ein erfolgreicher Aufruf einen Zeiger auf das erwartete Dateiobjekt zurückgibt:

   status = ObReferenceObjectByHandle (
                             AcpInfo->Handle,
                             0L,
                             DesiredAccess,
                             *IoFileObjectType,
                             Irp->RequestorMode,
                             (PVOID *)&AcpEndpointFileObject,
                             NULL);

   if ( !NT_SUCCESS(status) ) {
      goto complete;
   }
   AcpEndpoint = AcpEndpointFileObject->FsContext;

   if ( AcpEndpoint->Type != BlockTypeEndpoint )

Obwohl ObReferenceObjectByHandle einen Zeiger auf ein Dateiobjekt zurückgibt, hat der Treiber keine Garantie dafür, dass der Zeiger auf das erwartete Dateiobjekt verweist. In diesem Fall sollte der Treiber den Zeiger überprüfen, bevor er auf die treiberspezifischen Daten bei AcpEndpointFileObject-FsContext> zugreift.

Um solche Probleme zu vermeiden, sollte ein Treiber wie folgt auf gültige Daten prüfen:

  • Überprüfen Sie den Objekttyp, um sicherzustellen, dass er vom Treiber erwartet wird.

  • Stellen Sie sicher, dass der angeforderte Zugriff für den Objekttyp und die erforderlichen Aufgaben geeignet ist. Wenn Ihr Treiber beispielsweise eine schnelle Dateikopie ausführt, stellen Sie sicher, dass das Handle Lesezugriff hat.

  • Achten Sie darauf, den richtigen Zugriffsmodus (UserMode oder KernelMode) anzugeben und dass der Zugriffsmodus mit dem angeforderten Zugriff kompatibel ist.

  • Wenn der Treiber ein Handle für ein Dateiobjekt erwartet, das der Treiber selbst erstellt hat, überprüfen Sie das Handle für das Geräteobjekt oder den Treiber. Achten Sie jedoch darauf, keine Filter zu unterbrechen, die E/A-Anforderungen für seltsame Geräte senden.

  • Wenn Ihr Treiber mehrere Arten von Dateiobjekten unterstützt (z. B. die Steuerkanäle, Adressobjekte und Verbindungen von TDI-Treibern oder Volume-, Verzeichnis- und Dateiobjekten von Dateisystemen), stellen Sie sicher, dass Sie eine Möglichkeit haben, sie zu unterscheiden.

  • Last updated on