tdifw tdi_event_receive_datagram 问题

68 阅读 0 评论 45 点赞

我是靠谱客的博主友好花生，最近开发中收集的这篇文章主要介绍tdifw tdi_event_receive_datagram 问题，觉得挺不错的，现在分享给大家，希望可以做个参考。

概述

tdi过滤在tdifw基础上改的，发现在Windows2008上 tdi_event_receive_datagram函数老是蓝屏，用windbg查看dmp信息，定位到：

done:
   // cleanup
   if (ote_addr != NULL)
       KeReleaseSpinLock(&g_ot_hash_guard, irql);
//   if (request.sid_a != NULL)
//       free(request.sid_a);

   if (result == FILTER_ALLOW) {

       if(ctx->old_handler)
       {

           return ((PTDI_IND_RECEIVE_DATAGRAM)(ctx->old_handler))
               (ctx->old_context, SourceAddressLength, SourceAddress, OptionsLength,
               Options, ReceiveDatagramFlags, BytesIndicated, BytesAvailable, BytesTaken,
               Tsdu, IoRequestPacket);
       }
       else
       {
           return STATUS_DATA_NOT_ACCEPTED;
       }

   } else
       return STATUS_DATA_NOT_ACCEPTED;
}

上述红色部分导致蓝屏。查了当前的irql，是DISPATCH_LEVEL，查了ctx的内存都分配的NonPagedPool，所以不存在缺页问题。那么另一种可能就是ctx->old_handle是非法地址。

导致ctx->old_handle的可能原因是这个地址被释放了，但是这个函数前边有：

ote_addr = ot_find_fileobj(ctx->fileobj, &irql);
   if (ote_addr == NULL) {
       KdPrint(("[tdi_fw] tdi_receive_datagram: ot_find_fileobj(0x%x)!n", ctx->fileobj));
       goto done;

   }

代码能进入esult == FILTER_ALLOW逻辑，说明ctx->fileobj是有效的，但ctx->old_handle无效，可能原因是ctx->fileobj这个ID的ot_entry对象已经被释放了，ctx->old_handle被重新使用了，但ctx->fileobj地址没被擦除。这个可能性小。

而ctx->fileobj原来的ot_entry已经被释放了，然后系统又分配了同样ID的文件对象，这样导致ot_find_fileobj(ctx->fileobj, &irql);能找到ot_entry对象。

为此，在释放ot_entry时，强制对内容清0，在ot_del_fileobj函数中，释放前加上清除操作

memset(ote,0,sizeof(*ote));

free(ote);

测试果然不蓝屏了，bingo！