drv_query_volume_information: most branches write fixed-size structs without checking the output buffer length (pool overflow)

Audit finding against master @ a0648190 (v1.10).

Impact: kernel pool buffer overflow (write past the METHOD_BUFFERED system buffer), triggerable by an unprivileged process calling NtQueryVolumeInformationFile with an output buffer smaller than the structure being returned. Any handle to anything on the volume is enough — no special access required.

In drv_query_volume_information (src/btrfs.c ~1024-1229), Irp->AssociatedIrp.SystemBuffer is allocated by the I/O manager with exactly IrpSp->Parameters.QueryVolume.Length bytes, but most branches write a fixed-size structure unconditionally, e.g.:

case FileFsDeviceInformation:
{
    FILE_FS_DEVICE_INFORMATION* ffdi = Irp->AssociatedIrp.SystemBuffer;   // btrfs.c:1073
    ...
    ffdi->DeviceType = FILE_DEVICE_DISK;                                   // no Length check anywhere

The affected branches:

So e.g. NtQueryVolumeInformationFile(handle, FileFsObjectIdInformation, buf, 8, &ret) gives the driver an 8-byte system buffer, into which it writes 64 bytes.

By contrast, the FileFsAttributeInformation and FileFsVolumeInformation branches do compare against Parameters.QueryVolume.Length and return STATUS_BUFFER_OVERFLOW (although FileFsAttributeInformation still stores its 12-byte fixed header — FileSystemAttributes, MaximumComponentNameLength, FileSystemNameLength at btrfs.c:1053-1063 — before clamping only the name part).

Suggested fix: in each branch, verify IrpSp->Parameters.QueryVolume.Length >= sizeof(<struct>) before writing, and return STATUS_BUFFER_OVERFLOW otherwise (as FastFAT does); for the attribute branch, guard the fixed header with the same check.