ltfs/mkltfs segfault when the drive INQUIRY vendor id is not IBM/HP/HPE/QUANTUM (NULL deref in _raw_open)

Start with get_supported_devs() in src/tape_drivers/vendor_compat.c and the device-opening loops in src/tape_drivers/linux/sg/sg_tape.c and src/tape_drivers/freebsd/cam/cam_tc.c; compare them with the guarded loop in src/tape_drivers/osx/iokit/iokit_tape.c. Reproduce with an mhvtl drive reporting an unknown vendor, then verify that opening it reports LTFS30213I and exits 1 without a segfault.

What happens

Opening a tape drive whose INQUIRY vendor id is not one of IBM, HP, HPE
or QUANTUM crashes with SIGSEGV instead of being reported as an unsupported
drive.

# ltfs -o devname=/dev/sg9 /mnt/ltfs
...
LTFS17085I Plugin: Loading "sg" tape backend.
LTFS30209I Opening a device through sg-ibmtape driver (/dev/sg9).
# echo $?
139

139 is 128 + 11. The crash is immediately after INQUIRY and before any medium
command, so nothing touches the cartridge.

Why

get_supported_devs() in src/tape_drivers/vendor_compat.c:328 initialises
cur to NULL and its switch has no default, so an unknown vendor yields
NULL:

struct supported_device **get_supported_devs(int vendor)
{
        struct supported_device **cur = NULL;

        switch (vendor) {
                case VENDOR_IBM:     cur = ibm_supported_drives;     break;
                case VENDOR_HP:      cur = hp_supported_drives;      break;
                case VENDOR_QUANTUM: cur = quantum_supported_drives; break;
        }

        return cur;
}

get_vendor_id() (same file, line 314) returns VENDOR_UNKNOWN for anything
else. _raw_open() in src/tape_drivers/linux/sg/sg_tape.c:502 then does:

struct supported_device **cur = get_supported_devs(priv->vendor);
while(*cur) {                      /* <- NULL */

The intended path is three lines below, and is never reached:

} else {
        ltfsmsg(LTFS_INFO, 30213I, id_data.vendor_id, id_data.product_id);
        close(priv->dev.fd);
        priv->dev.fd = -1;
        return -EDEV_DEVICE_UNSUPPORTABLE;
}

src/tape_drivers/freebsd/cam/cam_tc.c:284 has the same unguarded loop.
src/tape_drivers/osx/iokit/iokit_tape.c:861 already guards it with
while(cur && *cur), which is the fix.

Note: the device list does not warn you

ltfs -o device_list shows such a drive with a product name, because
sg_get_device_list() names it through _generate_product_name()
(sg_tape.c:4358), which matches on product id alone and only against the
IBM and HP tables. So a drive is listed as though it were known, and crashes
when opened:

Device Name = /dev/sg9 (16.0.19.0), Vendor ID = STK     , Product ID = ULT3580-TD8     , Product Name =[ULT3580-TD8].

How to reproduce without the hardware

With mhvtl, which lets a virtual drive
present any identity. In /etc/mhvtl/device.conf:

Drive: 51 CHANNEL: 00 TARGET: 19 LUN: 00
 Library ID: 50 Slot: 01
 Vendor identification: STK
 Product identification: ULT3580-TD8

Then ltfs -o devname=/dev/sgN /mnt/point on that drive's sg node.

This is not a contrived configuration. A StorageTek SL500 with LTO drives
is a real product: the library reports vendor STK while the drives inside it
carry IBM part numbers. So any tool that builds an STK-profile virtual library
with LTO drives produces this pairing by describing the hardware correctly. In
the management console I use, the STK profile offers
ULT3580-TD3 through ULT3580-TDA under drive_vendor: STK.

For what it is worth, most profiles are unaffected because they report IBM —
ADIC, DELL, Overland and Spectra libraries OEM IBM mechanisms and say so. Of
nine vendor profiles, seven produce a vendor id LTFS knows. STK is the one
that both reaches this code and appears in device_list, because its product
ids are in your IBM table even though its vendor id is not.

Still present in

main, release/v2.4.9.0 and release/v2.4.9.1 — all three are at efc9e3a
at the time of writing, and sg_tape.c:503, cam_tc.c:284 and
vendor_compat.c:328 are unchanged there.

Environment

• LTFS 2.4.9.0 (Prelim), LTFS Format Specification 2.4.0, built from
  v2.4.9.0-10523
• Rocky Linux 9.8, kernel 5.14.0-687.47.1.el9_8.x86_64, gcc 11.5.0
• sg backend, ./configure --disable-snmp
• mhvtl 1.8

Fix

A pull request follows, against release/v2.4.9.1: while(cur && *cur) in the
sg and cam backends, matching what iokit already does. Verified on the
environment above — the same command now logs
LTFS30213I Unsupported Drive 'STK ' / 'ULT3580-TD8 '. and exits 1.

The FreeBSD half is the identical expression in the identical position but is
not compiled or tested here; happy to drop it if you would rather it went
separately.