CVE-2026-46169: hfsplus: fix uninit-value by validating catalog record size

In the Linux kernel, the following vulnerability has been resolved:

hfsplus: fix uninit-value by validating catalog record size

Syzbot reported a KMSAN uninit-value issue in hfsplusstrcasecmp(). The root cause is that hfsbrecread() doesn't validate that the on-disk record size matches the expected size for the record type being read.

When mounting a corrupted filesystem, hfsbrecread() may read less data than expected. For example, when reading a catalog thread record, the debug output showed:

HFSPLUSBRECREAD: reclen=520, fd->entrylength=26 HFSPLUSBRECREAD: WARNING - entrylength (26) < reclen (520) - PARTIAL READ!

hfsbrecread() only validates that entrylength is not greater than the buffer size, but doesn't check if it's less than expected. It successfully reads 26 bytes into a 520-byte structure and returns success, leaving 494 bytes uninitialized.

This uninitialized data in tmp.thread.nodeName then gets copied by hfspluscatbuildkeyuni() and used by hfsplusstrcasecmp(), triggering the KMSAN warning when the uninitialized bytes are used as array indices in casefold().

Fix by introducing hfsplusbrecreadcat() wrapper that: 1. Calls hfsbrecread() to read the data 2. Validates the record size based on the type field: - Fixed size for folder and file records - Variable size for thread records (depends on string length) 3. Returns -EIO if size doesn't match expected

For thread records, check against HFSPLUSMINTHREADSZ before reading nodeName.length to avoid reading uninitialized data at call sites that don't zero-initialize the entry structure.

Also initialize the tmp variable in hfsplusfindcat() as defensive programming to ensure no uninitialized data even if validation is bypassed.