Partager via

Défaut de validation des gestionnaires d'objets

Certains pilotes doivent manipuler des objets passés à eux par des appelants ou doivent gérer deux objets de fichier en même temps. Par exemple, un pilote de modem peut recevoir un handle vers un objet d’événement, ou un pilote réseau peut recevoir des handles sur deux objets de fichier différents. Le pilote doit valider ces handles. Étant donné qu’ils sont passés par un appelant et non par le biais du gestionnaire d’E/S, le gestionnaire d’E/S ne peut pas effectuer de vérifications de validation.

Par exemple, dans l’extrait de code suivant, le pilote a reçu le descripteur AscInfo->AddressHandle, mais ne l’a pas validé avant d’appeler ObReferenceObjectByHandle :

   //
   // 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) ) {

Bien que l’appel à ObReferenceObjectByHandle réussisse, le code ne parvient pas à s’assurer que le pointeur retourné fait référence à un objet de fichier ; il fait confiance à l’appelant pour transmettre les informations appropriées.

Même si tous les paramètres de l’appel à ObReferenceObjectByHandle sont corrects et que l’appel réussit, un pilote peut toujours obtenir des résultats inattendus si l’objet de fichier n’est pas destiné à son pilote. Dans le fragment de code suivant, le pilote suppose qu’un appel réussi retourne un pointeur vers l’objet de fichier attendu :

   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 )

Bien que ObReferenceObjectByHandle retourne un pointeur vers un objet de fichier, le pilote n’a aucune garantie que le pointeur référence l’objet de fichier attendu. Dans ce cas, le pilote doit valider le pointeur avant d’accéder aux données spécifiques au pilote sur AcpEndpointFileObject-FsContext>.

Pour éviter de tels problèmes, un pilote doit rechercher des données valides, comme suit :

  • Vérifiez le type d’objet pour vous assurer qu’il s’agit de ce que le pilote attend.

  • Vérifiez que l’accès demandé est approprié pour le type d’objet et les tâches requises. Si votre pilote effectue une copie rapide de fichiers, par exemple, assurez-vous que le handle dispose d’un accès en lecture.

  • Veillez à spécifier le mode d’accès correct (UserMode ou KernelMode) et que le mode d’accès est compatible avec l’accès demandé.

  • Si le pilote attend un handle à un objet de fichier que le pilote lui-même a créé, validez le handle sur l’objet ou le pilote de périphérique. Toutefois, veillez à ne pas interrompre les filtres qui envoient des demandes d’E/S pour des appareils étranges.

  • Si votre pilote prend en charge plusieurs types d’objets de fichiers (tels que les canaux de contrôle, les objets d’adressage et les connexions des pilotes TDI ou des objets volume, répertoire et fichier de systèmes de fichiers), assurez-vous d’avoir un moyen de les différencier.

  • Last updated on