Remove absolute registry path in filter driver for 26H1 HLK

[5656hcx]

Summary

Windows 26H1 HLK test fails with:

Registry operations should not use absolute paths. Detected opening of
unisolated registry key \REGISTRY\MACHINE\SYSTEM\CurrentControlSet\Enum\USB\VID_0489&PID_E159
Module: qcusbfilter.sys

Fix

qcfilter.c

1. Implement QCFilterSetFriendlyName: writes FriendlyName (REG_SZ) to the device hardware key (HKLM\SYSTEM\CurrentControlSet\Enum\...\<instance>) using only no hard-coded absolute registry paths:

   • Open Device Parameters via IoOpenDeviceRegistryKey(PDO, PLUGPLAY_REGKEY_DEVICE)
   • Derive the hardware key path from ZwQueryKey(KeyNameInformation) and stripping the \Device Parameters suffix.
   • Open the resulting path with ZwOpenKey(KEY_SET_VALUE).
   • Write the value with ZwSetValueKey(REG_SZ), including the null terminator (Length + sizeof(WCHAR)).
   • All handles and pool allocations are released on every code path.

2. Fix null-pointer issue in QCFilterCreateFriendlyName: add && pSwInstance != NULL guard before passing pSwInstance to RtlStringCbCatW, preventing a kernel crash when the driver key path does not contain a \ separator.

Testing

• Validate the device hardware key, friendly name is set correctly. Need customer to verify with 26H1 HLK.

[hangzqcom]

ZwSetValueKey is called with size FriendlyName->Length + sizeof(WCHAR), reading one WCHAR past the end of the declared string data. UNICODE_STRING.Length never includes a null terminator, so this is only safe when FriendlyName->MaximumLength >= FriendlyName->Length + sizeof(WCHAR). The validation at the top checks Length==0 but not MaximumLength. A caller passing a UNICODE_STRING whose buffer is exactly Length bytes with no trailing null triggers an out-of-bounds read. Add a guard before ZwSetValueKey: if (FriendlyName->MaximumLength < FriendlyName->Length + sizeof(WCHAR)) { ZwClose(hHwKey); return STATUS_INVALID_PARAMETER; }

[hangzqcom]

When the first ZwQueryKey size-query call returns an unexpected status (neither STATUS_BUFFER_TOO_SMALL nor STATUS_BUFFER_OVERFLOW), the original ntStatus is discarded and the generic STATUS_UNSUCCESSFUL is returned. This makes it impossible to distinguish STATUS_ACCESS_DENIED from STATUS_INVALID_HANDLE in diagnostics. Maybe return ntStatus directly instead of STATUS_UNSUCCESSFUL to preserve the original error code?

[hangzqcom]

KEY_NAME_INFORMATION.NameLength to USHORT, potential overflow? I know it won't be common but still.