drivers/libusb{0,1}.c: bound rdlens loop by element count, not sizeof

[0x-a6]

nut_libusb_open() iterates the two candidate HID report descriptor lengths:

	int32_t rdlen1, rdlen2, rdlens[2];
	size_t j;
	...
	for (j = 0; j < sizeof(rdlens); j++) {
		rdlen = rdlens[j];

sizeof(rdlens) is the size in bytes (8), not the element count (2), so the loop reads rdlens[2..7] — 24 bytes past the end of the array — and uses that stack garbage as rdlen. The "ran out of candidates" test after the loop (if (j >= sizeof(rdlens))) has the same bug, so it never fires as intended either.

The out-of-range indices are only reached when neither real candidate satisfies the caller — i.e. exactly when a device is in a bad state and both descriptor reads fail, which is when you least want undefined behaviour. Garbage that happens to survive the rdlen sanity checks is then passed to libusb_control_transfer() and on to the HID parser callback, which is where it segfaults.

How it showed up

usbhid-ups segfaulting against an EcoFlow DELTA 3 Plus (3746:ffff) on an NVIDIA Jetson Orin Nano (aarch64, NUT built from v2.8.5) after the device's USB connection had wedged. usbreset on the device cleared the wedge, and the crash went away with it — the descriptor reads then succeeded on the first candidate and the loop never ran past index 0.

Fix

Use SIZEOF_ARRAY() from include/common.h, which both files already include. drivers/libusb0.c carries the identical defect in the same two places and is fixed the same way.

Regression from aba6f43 ("if the tried rdlen did not succeed, fall back to the other value we had in mind" [#3136]), first released in v2.8.5.

Happy to add a NEWS.adoc entry under the 2.8.6 section if you'd like one — I left it out to keep the diff to the fix, since the entry would want this PR's number.

[github-actions]

A ZIP file with standard source tarball and another tarball with pre-built docs for commit c736ec5 is temporarily available: NUT-tarballs-PR-3550.zip.

[AppVeyorBot]

✅ Build nut 2.8.5.4994-master completed (commit 616551d00b by @0x-a6)

• artifacts
• A 7-zip archive with built NUT for Windows debug binaries is temporarily available: NUT-for-Windows-x86_64-SNAPSHOT-2.8.5.4994-master.7z

[jimklimov]

My bad, thanks for the catch and fix! A news entry would be appropriate, perhaps with a new block like - Fix fallout of development in ... seen for some earlier releases. Maybe without reference to specific commit (rather to PR number) to avoid the hassle with nut.dict :)

[0x-a6]

Added to common code, but happy to put it into it's own block.

[jimklimov]

Thanks, ok for now - I've actually added such a block in #3551 so will (hopefully remember to) relocate your entry there after both PRs get merged.

[AppVeyorBot]

✅ Build nut 2.8.5.4995-master completed (commit 49b5e096be by @0x-a6)

• artifacts
• A 7-zip archive with built NUT for Windows debug binaries is temporarily available: NUT-for-Windows-x86_64-SNAPSHOT-2.8.5.4995-master.7z

[AppVeyorBot]

✅ Build nut 2.8.5.4996-master completed (commit dbb3df6b8d by @0x-a6)

• artifacts
• A 7-zip archive with built NUT for Windows debug binaries is temporarily available: NUT-for-Windows-x86_64-SNAPSHOT-2.8.5.4996-master.7z