Hacktoberfest 2026 : les issues que les mainteneurs ont marquées pour octobre, ouvertes et accessibles aux débutants. Parcourir les issues Hacktoberfest

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

Ouverte
  • Quelque chose ne va pas ?
#650 0 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Personne n'a encore pris cette issue.

Évaluation

Difficulté
2/5
Temps estimé
1-3 heures
Accessibilité débutants
25/100
Type d'issue
Bug
Clarté
Clairement spécifiée
Activité
Active
Stack technique
c
Domaine
backend, operating-systems

Piste de recherche

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.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

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.

Langage dominant
C
Étoiles
354
Forks
111
Merge moyen
2 h 1 min
PR mergées (30 j)
2

Préparer son environnement

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de LinearTapeFileSystem/ltfs

Toutes les issues de LinearTapeFileSystem/ltfs

Issues similaires

Plus d'issues C

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.