Is it possible to send IOCTL to USBD from minifilter space?

Hi experts,
What I want to achieve is to uniquely identify USB storage devices and control file access within them.
I know that the serial number info is optional and there may be some devices lacking that string descriptor. But my policy is to deny access to such devices.
so now I need VID, PID and serial number information for a USB device.
I am putting my USB detection logic in instance setup where I can set an instance context for access control data.
Till now I tried using FltDeviceIoControlFile with IOCTL_STORAGE_QUERY_PROPERTY and detecting bus type for USB bus type. It works successfully.
But I noticed it does not contain the VID and PID I need. what is there is a mere optional string description to the information I need.

Now I want to know is there a way for obtaining VID and PID in minifilter, probably like sending some IOCTL to USBD obtaining raw USB device descriptor. Or I should use another driver or user mode agent to obtain this info?

the rest is not related to the question but some funny experience I had and thought it might be good to share

Also I found out that these strings (vendor device and serial) in USB standard are stored in unicode format. But STORAGE_DEVICE_DESCRIPTOR structure(the returned data is of this structure type) documentation says the strings are null-terminated ASCII format.
I tested 2 different devices, an external hard driver and a USB stick.
The external hard drive has 3 strings in ASCII format as the STORAGE_DEVICE_DESCRIPTOR documentation implies.

The memory layout starting with structure address:
VendorIdOffset = 0x48 productIdOffset = 0x51 serialNumberOffset = 0x67

0xFFFFE00056003A90 28 00 00 00 78 00 00 00 00 00 00 00 48 00 00 00 (…x…H…
0xFFFFE00056003AA0 51 00 00 00 62 00 00 00 67 00 00 00 07 00 00 00 Q…b…g…
0xFFFFE00056003AB0 24 00 00 00 00 00 06 12 5b 00 00 00 57 44 20 20 $…[…WD
0xFFFFE00056003AC0 20 20 20 20 45 6c 65 6d 65 6e 74 73 20 31 30 42 Elements 10B
0xFFFFE00056003AD0 38 20 20 20 31 30 31 32 57 44 20 20 20 20 20 20 8 1012WD
0xFFFFE00056003AE0 00 45 6c 65 6d 65 6e 74 73 20 31 30 42 38 20 20 .Elements 10B8
0xFFFFE00056003AF0 20 00 31 30 31 32 00 57 58 32 31 45 39 34 44 48 .1012.WX21E94DH
0xFFFFE00056003B00 4e 58 45 20 20 20 20 00 00 00 00 00 00 00 00 00 NXE …

The serial number field returned for the USB stick has one byte offset with what is specified in STORAGE_DEVICE_DESCRIPTOR.SerialNumberOffset and is in unicode format! the other 2 strings are null terminated ASCII format. I feel like windows is converting strings to ASCII but fails to convert the serial number string because the USB stick device descriptor reports serial number descriptor one byte off. well the driver details in device manager and usbview.exe in usermode report the correct ASCII string for this device though.

The memory layout starting with structure address:
VendorIdOffset = 0x48 productIdOffset = 0x51 serialNumberOffset = 0x67

0xFFFFE00056003DB0 28 00 00 00 7a 00 00 00 00 00 01 00 48 00 00 00 (…z…H…
0xFFFFE00056003DC0 51 00 00 00 62 00 00 00 67 00 00 00 07 00 00 00 Q…b…g…
0xFFFFE00056003DD0 24 00 00 00 00 80 04 02 1f 00 00 00 47 65 6e 65 $…€…Gene
0xFFFFE00056003DE0 72 69 63 20 46 6c 61 73 68 20 44 69 73 6b 20 20 ric Flash Disk
0xFFFFE00056003DF0 20 20 20 20 38 2e 30 37 47 65 6e 65 72 69 63 20 8.07Generic
0xFFFFE00056003E00 00 46 6c 61 73 68 20 44 69 73 6b 20 20 20 20 20 .Flash Disk
0xFFFFE00056003E10 20 00 38 2e 30 37 00 03 39 00 32 00 38 00 34 00 .8.07…9.2.8.4.
0xFFFFE00056003E20 34 00 37 00 37 00 30 00 01 00 00 00 00 00 00 00 4.7.7.0…

Am I right does this USB stick report serial number one byte off?

I’m dubious about the serial number used as a security boundary, but
Usbview shows how to query USB descriptors (it’s a user mode sample but the IOCTLs work in kernel mode as well). Note that I’ve never tried to send these from an FS filter and it might be difficult to identify the correct target device stack.

Thanks for the answer.