Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

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

Đang mở
  • Có gì không ổn?
#650 0 bình luận 0 reaction 0 người được giao Xem trên GitHub

Chưa có ai nhận issue này.

Đánh giá

Độ khó
2/5
Thời gian dự kiến
1-3 giờ
Mức phù hợp với người mới
25/100
Loại issue
Lỗi
Độ rõ ràng
Đặc tả rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
c
Lĩnh vực
backend, operating-systems

Hướng nghiên cứu

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.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

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.

Ngôn ngữ chính
C
Star
352
Fork
110
Merge trung bình
2 giờ 1 phút
Pull request đã merge (30 ngày)
2

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của LinearTapeFileSystem/ltfs

Tất cả issue của LinearTapeFileSystem/ltfs

Issue tương tự

Thêm issue về C

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.