Cloudanix VulnDB

CVE-2026-99019

None

CVSS

—

EPSS

0.2%

Published

Oct 23, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A Linux kernel bug tied to certain storage hardware can slowly leak resources, eventually forcing restarts and blocking normal device operations.

Exploitation
Local Privilege
Attacker needs
Local User
Complexity
Theoretical
Impact
Denial Of Service
Component
OS kernel
Class
Other
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

The SCSI changer driver in the Linux kernel performs scsi_device_lookup on data transfer elements without ever dropping the acquired reference, leaving scsi_device objects pinned on the host list and preventing release, new device insertion at the same address, and low-level driver module unload.

Why it matters to the business

Storage systems using tape or media changers experience gradual resource exhaustion that blocks hardware reconfiguration and forces full reboots, increasing downtime and operational cost in environments that rely on removable media libraries.

How an attack unfolds

An attacker or automated process repeatedly creates and removes virtual or physical changers that report drive SCSI IDs; each cycle leaks references counted by the module use count, eventually causing target_core_pscsi and other walkers to reject new devices and preventing module unload until reboot.

How to fix it

Apply the upstream fix that drops the scsi_device reference immediately after printing vendor/model/revision information and removes the now-unused dt[] array; rebuild and deploy the patched kernel to affected hosts.

How to confirm the fix worked

After patching, create and destroy changers multiple times while confirming that the ch module use count remains unchanged and that scsi_device objects are released on removal; inspect kernel logs for absence of prior reference-leak symptoms.

Typical attack path

  1. Locate a system exposing the ch driver to a compatible changer (physical or virtual such as mhvtl)
  2. Trigger repeated library create/remove operations that cause ch_readconfig to run
  3. Observe steadily increasing module reference count via lsmod
  4. Attempt device insertion or module unload to trigger denial-of-service symptoms
  5. Force reboot to recover

How to detect it

Review kernel logs for repeated scsi_device_get failures or target_core_pscsi errors; track ch module use count via lsmod across create/remove cycles; examine dmesg for reference leaks reported during device removal.

What your security team should do

  • Prioritize kernel updates on any host that binds the ch module or uses SCSI media changers
  • Add monitoring for module reference count growth and scsi_device_get failures in storage fleets
  • Document reboot recovery procedures for affected systems until patches are deployed

The record

In the Linux kernel, the following vulnerability has been resolved: scsi: ch: Do not keep references to data transfer element devices ch_readconfig() looks up the scsi_device of every data transfer element whose SCSI id the changer reports in READ ELEMENT STATUS, and stores it in ch->dt[]. scsi_device_lookup() takes a reference, and nothing ever drops it: ch_destroy() frees the array with kfree(). ch->dt[] is read nowhere else - it only supplies the vendor, model and revision printed in the same loop. Once such a drive is removed, its scsi_device can never be released. It stays on the host's device list at its address, so a new device there is refused by anything that walks the list - target_core_pscsi reports "scsi_device_get() failed for H:C:T:L" - and the low-level driver's module can no longer be unloaded. Only a reboot recovers. It shows with any changer that reports its drives' ids; with the mhvtl virtual library (IBM 3573-TL personality), each create and remove of a library with four drives leaves four references behind, counted by the module's use count in lsmod. With ch not bound the count is unchanged, and with this patch applied it is unchanged too. Drop the reference as soon as the name has been printed, and remove the now unused dt[] array. That also removes the array leaked when ch_probe() fails after ch_readconfig(). The same leak was reported with an RFC patch in 2022, which was not merged.

Affected packages

Ecosystem Package Introduced Fixed