null-terminate device name copies in linux device sort

[aizu-m]

ASan, with a driver that fills all 256 bytes of deviceName and no terminator:

READ of size 257 ... heap-buffer-overflow
#0 printf_common
#2 linux_read_sorted_physical_devices loader_linux.c

Was reading through the physical-device sort path. The loader copies the driver-reported deviceName into its own LinuxSortedDeviceInfo with strncpy bounded by the full VK_MAX_PHYSICAL_DEVICE_NAME_SIZE. strncpy leaves no terminator when the source occupies the whole field, so a driver that returns a 256-byte name produces an unterminated device_name. That field is then logged with %s, so the read runs off the end of the buffer, past the heap allocation for the last sorted entry.

We make our own copy here, so the termination has to be guaranteed on our side rather than trusted from the driver. The same copy is in linux_sort_physical_device_groups. Both now bound the copy to SIZE-1 and write the terminator, matching the strncpy plus explicit nul already used in loader_windows.c.

[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 13056.

[charles-lunarg]

This is a good defensive check, but at least according to the spec this string must be null terminated

deviceName is an array of VK_MAX_PHYSICAL_DEVICE_NAME_SIZE char containing a null-terminated UTF-8 string which is the name of the device.

https://docs.vulkan.org/refpages/latest/refpages/source/VkPhysicalDeviceProperties.html

Just wanted to post that the code in a way was behaving as designed. But well, strncpy and memcpy are great vectors of bugs so being defensive is very welcome.

[ci-tester-lunarg]

CI Vulkan-Loader build # 3574 running.

[ci-tester-lunarg]

CI Vulkan-Loader build # 3574 passed.