Compatibility with Rising antivirus software about dokany HOT 8 OPEN

Hi @fcyinxunpeng ,

RequestContext->Irp->MdlAddress be filled by the program of antivirus software?

It technically could but I believe it shouldn't provide one as the current IRP major is IRP_MJ_DIRECTORY_CONTROL
https://learn.microsoft.com/en-us/windows-hardware/drivers/ddi/wdm/ns-wdm-_irp

Pointer to an MDL describing a user buffer, if the driver is using direct I/O, and the IRP major function code is one of the following:

    IRP_MJ_READ

    The MDL describes an empty buffer that the device or driver fills in.

    IRP_MJ_WRITE

    The MDL describes a buffer that contains data for the device or driver.

    IRP_MJ_DEVICE_CONTROL or IRP_MJ_INTERNAL_DEVICE_CONTROL

    If the IOCTL code specifies the METHOD_IN_DIRECT transfer type, the MDL describes a buffer that contains data for the device or driver.

Normally we should allocate that MDL from the UserBuffer and own it but due to how the code is written, we try to use their.

We could change our code to override their value by removing this check and the same one in DokanAllocateMdl to ignore their (bogus?) value.

from dokany.

Hi @Liryna ,
Thanks for your reply.
I removed this check and the same one in DokanAllocateMdl()

If I zero memory in DokanQueryDirecory():

 if (RequestContext->Irp->MdlAddress == NULL) {
    ...
 }else{
    // test code
    buffer = MmGetSystemAddressForMdlNormalSafe(RequestContext->Irp->MdlAddress);
    RtlZeroMemory(buffer, bufferLen);  // won't crash at this line
}

Dokany2.sys doesn't crash at this line of code, so RequestContext->Irp->MdlAddress is valid at this moment.
Maybe then the antivirus software free the content of RequestContext->Irp->MdlAddress , even though dokany2.sys returns a STATUS_PENDING?

from dokany.

Thanks for testing!
Yeah that could be possible. Would you be able to contact Rising so they can look into this on their side ?

from dokany.

OK, I intend to ask for official help.
And I found that the MmGetSystemAddressForMdlNormalSafe function returns a user-space address instead of a kernel-space address when I use antivirus software scanning.

from dokany.

This is the official reply of rising:

The problem is that when traversing the directory, Rising Anti-Virus Software V17 passes in a user-mode address, causing a blue screen when the dokany driver writes to this address.
You can suggest to dokany that you add a method to determine whether the request mode is user mode, or after detecting the user mode address, use the writing method of the user mode address, such as __try __except and so on.

But I think the real reason is that the anti-virus software modified the address of MmGetSystemAddressForMdlNormalSafe() to point to user space, but this address is only valid in the current context. When dokany is executing DokanCompleteDirectoryControl(), this address is invalid.

from dokany.

Thanks @fcyinxunpeng ! I am not sure about their answer. I believe we do everything correctly. We try catch and lock the page when we receive the request

I agree with you that they might not wait for our completion and do something with the buffer they gave us and things go wrong.

from dokany.

@fcyinxunpeng Were you able to get more info from Rising ?

from dokany.