The guard page causes an attempt to write past the end of the allocation to result in an immediate bugcheck. Special pool also configures the driver’s allocation at the end of the page and sets the next virtual page as a guard page by marking it as invalid. This helps prevent drivers from accidentally writing to another driver’s memory. Special pool changes the organization of the pool so that each driver’s allocation is in a separate page of memory. To catch the driver that corrupted pool we can use special pool. In Part 1 we demonstrated this type of buffer overflow using NotMyFault, but we were not able to identify which code had corrupted the pool. With pool organized as shown in Figure 1, if DriverA allocates 100 bytes but writes 120 bytes it will overwrite the pool header and data stored by DriverB. However this sharing requires that each driver be careful in how it uses pool, any bugs where the driver uses pool improperly may corrupt the pool of other drivers and cause a crash. By allowing multiple drivers to share the same page, pool provides for an efficient use of the available kernel memory space. Pool is typically organized to allow multiple drivers to store data in the same page of memory, as shown in Figure 1. In this article we will discuss how special pool can help identify the driver that writes too much data. In our previous article we discussed pool corruption that occurs when a driver writes too much data in a buffer.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |