loader: fix heap overflow when registry path exceeds reg_data buffer

[aizu-m]

Reading the registry path code I noticed reg_data is allocated at total_size (4096 by default) but each snprintf in windows_add_json_entry is bounded by json_size, the registry value size that windows_get_device_registry_entry reads with RegQueryValueEx (and the D3DKMT adapter query passes in). That size is uncapped. Pulling the buffer logic out into a small harness, a 9000-byte driver/layer JSON path lands like this:

buffer capacity=4096, wrote=9000 bytes, canary bytes clobbered=16/16

The NULL branch never checks json_size against total_size, and the realloc branch only doubles the size once, so any single REG_SZ/REG_MULTI_SZ path longer than the buffer overflows it.

Grow the buffer until the value actually fits and bound each snprintf by the remaining destination space. windows_get_registry_files has the same single-double plus source-length-bounded snprintf shape (its name is capped at 2048 so it is only an off-by-one at the capacity boundary) and gets the same treatment.

[ci-tester-lunarg]

Author aizu-m not on autobuild list. Waiting for curator authorization before starting CI build.

[ci-tester-lunarg]

Author aizu-m not on autobuild list. Waiting for curator authorization before starting CI build.

[ci-tester-lunarg]

CI Vulkan-Loader build queued with queue ID 761419.

[ci-tester-lunarg]

CI Vulkan-Loader build # 3506 running.

[ci-tester-lunarg]

CI Vulkan-Loader build # 3506 aborted.

[ci-tester-lunarg]

CI Vulkan-Loader build queued with queue ID 761647.

[ci-tester-lunarg]

CI Vulkan-Loader build # 3508 running.

[ci-tester-lunarg]

CI Vulkan-Loader build # 3508 passed.

[charles-lunarg]

This is solving the same thing that #1919 solved. I am closing as it is no longer needed, but I would appreciate any attention on #1923 which refactors the code to make the pattern of combining search paths into a single string into multiple strings.

[aizu-m]

Yeah, agreed. #1919 lands the same three fixes in windows_add_json_entry: the initial-alloc sizing, the single-double growth, and the writes being bounded by source length instead of remaining capacity. No reason to keep this open alongside it. I'll take a look at #1923.