Cloudanix VulnDB

CVE-2026-99156

None

CVSS

—

EPSS

0.2%

Published

Oct 28, 2026

CISA due date

—

Cloudanix analysis

Next patch cycle SSVC: Track

A recently fixed race condition in the Linux kernel's tape drive handling could let a local attacker crash the system or potentially run code by opening and removing a device at the same time.

Exploitation
Local Privilege
Attacker needs
Local User
Complexity
Moderate
Impact
Privilege Gain
Component
OS kernel
Class
Use After Free
Remediation
Patch
Effort
Medium
Patch risk
Low

What it actually does

Use-after-free in the SCSI tape driver where st_remove() frees a scsi_tape structure via kref_put() while it remains visible in st_index_idr, allowing a concurrent st_open() via scsi_tape_get() to obtain and dereference the freed object under st_ref_mutex.

Why it matters to the business

Kernel memory corruption or crashes on systems exposing SCSI tape character devices, potentially leading to denial of service or local privilege escalation; newly public flaw with minimal time for defensive preparation.

How an attack unfolds

An attacker with local access triggers concurrent st_remove() (device unplug or driver unload) and st_open() calls; st_remove drops the reference before unpublishing the IDR entry, allowing the open path to kref_get a freed object and trigger slab-use-after-free.

How to fix it

Apply the upstream fix that removes the IDR index before the final kref_put, all protected by st_ref_mutex; rebuild and deploy the patched kernel; disable the st module if SCSI tape devices are not required.

How to confirm the fix worked

Confirm the ordering change in st_remove (IDR removal precedes kref_put) is present in the running kernel source; attempt to reproduce the original race condition and verify absence of KASAN reports mentioning st_open or st_remove.

Typical attack path

  1. Obtain local unprivileged access on a Linux system with the st driver loaded
  2. Trigger device removal or driver unload while holding or racing an open on the tape character device
  3. st_remove executes kref_put before IDR removal under st_ref_mutex
  4. Concurrent st_open path in scsi_tape_get acquires the freed pointer and performs kref_get
  5. Resulting slab-use-after-free causes KASAN-detected corruption or kernel panic

How to detect it

Search kernel logs and KASAN reports for slab-use-after-free mentions tied to st_open or st_remove; inspect call traces containing drivers/scsi/st.c and chrdev_open; correlate with device removal events on systems exposing /dev/st* or /dev/nst*.

  • BUG: KASAN: slab-use-after-free in st_open
  • st_open (drivers/scsi/st.c:254
  • st_remove (drivers/scsi/st.c:4512)
  • Freed by task ...: kfree st_remove

What your security team should do

  • Immediately evaluate kernel upgrade priority given one-day public disclosure window
  • Audit systems for presence of the st SCSI tape driver and loaded tape devices
  • Temporarily blacklist the st module on non-tape systems until patched kernels are deployed
  • Monitor kernel logs for KASAN or slab-use-after-free reports involving st.c

The record

In the Linux kernel, the following vulnerability has been resolved: scsi: st: Fix use-after-free race between st_remove() and st_open() st_remove() drops the probe reference on the scsi_tape with kref_put() and only afterwards removes its index from st_index_idr. If that was the last reference, scsi_tape_release() frees the structure while it is still published in the idr. scsi_tape_get(), called from st_open(), looks up the tape in st_index_idr and takes a reference under st_ref_mutex and st_index_lock. remove_cdevs() does not wait for opens that are already past chrdev_open(), so an open that is blocked on st_ref_mutex while st_remove() holds it can take the mutex as soon as st_remove() drops it, find the freed tpnt in the idr and call kref_get() on it: BUG: KASAN: slab-use-after-free in st_open Write of size 4 ... st_open (drivers/scsi/st.c:254 drivers/scsi/st.c:1291) chrdev_open ... Freed by task ...: kfree st_remove (drivers/scsi/st.c:4512) Remove the index from the idr before dropping the reference, all under st_ref_mutex. A concurrent scsi_tape_get() now either runs first and holds a valid reference that keeps the tape alive, or runs afterwards and finds nothing, so st_open() fails with -ENXIO. This restores the ordering st_remove() had before the conversion to st_index_idr, where the tape was unpublished from scsi_tapes[] before the final kref_put().

Affected packages

Ecosystem Package Introduced Fixed