CVE-2026-23296: Linux Kernel Privilege Escalation Flaw

CVE-2026-23296 Overview

A reference count leak vulnerability exists in the Linux kernel's SCSI core subsystem that can cause a system hang when tearing down SCSI hosts. The vulnerability is located in the tagset_refcnt reference counting mechanism, where improper handling of reference counts leads to a resource leak condition that prevents proper cleanup of SCSI device structures.

This vulnerability specifically affects iSCSI operations, where the iscsid daemon can become unresponsive during session teardown operations. The call trace shows the hang occurring in scsi_remove_host when attempting to destroy an iSCSI TCP session, indicating that the reference count is never properly decremented, causing the removal operation to wait indefinitely.

Critical Impact

This vulnerability can cause system hangs and denial of service conditions when managing iSCSI storage connections, particularly affecting enterprise storage environments and virtualization platforms that rely on iSCSI connectivity.

Affected Products

• Linux Kernel (multiple stable branches affected)
• Systems using iSCSI TCP (iscsi_tcp module)
• Systems utilizing scsi_transport_iscsi module

Discovery Timeline

• 2026-03-25 - CVE CVE-2026-23296 published to NVD
• 2026-03-25 - Last updated in NVD database

Technical Details for CVE-2026-23296

Vulnerability Analysis

The vulnerability stems from improper reference counting in the SCSI subsystem's tag set management. When SCSI devices are allocated and deallocated, the tagset_refcnt counter must be properly incremented and decremented to track active references. In the affected code paths, certain error conditions or timing scenarios cause the reference count to not be properly decremented, resulting in a memory leak that accumulates over time.

The leaked references prevent the completion of the scsi_remove_host function, which waits for all tag set references to be released before proceeding. This creates a deadlock condition where the calling process (such as iscsid) blocks indefinitely in __wait_for_common, consuming system resources and preventing normal iSCSI operations.

The kernel log message scsi_alloc_sdev: Allocation failure during SCSI scanning, some SCSI devices might not be configured indicates that memory pressure from the leak can also affect new device allocations, compounding the impact.

Root Cause

The root cause is a missing or improperly placed reference count decrement in the SCSI device allocation and deallocation code paths. Specifically, when scsi_alloc_sdev fails or when certain error handling paths are taken during SCSI scanning, the tagset_refcnt is not properly decremented, leaving orphaned references.

The reference count leak occurs in the scsi/core subsystem where the tag set reference counting mechanism fails to account for all code paths that acquire references. This is a classic resource management bug where the "acquire" and "release" operations are not properly balanced across all possible execution flows.

Attack Vector

This vulnerability is exploitable through local access to the system, requiring the ability to trigger iSCSI session creation and destruction cycles. The attack vector involves repeatedly initiating iSCSI connections and disconnections, which accumulates leaked references until the system becomes unresponsive.

An attacker with local privileges could exploit this vulnerability to cause a denial of service condition by:

1. Establishing multiple iSCSI sessions to trigger SCSI device allocation
2. Rapidly tearing down sessions to trigger the reference count leak
3. Repeating until the system hangs or becomes unresponsive

The vulnerability affects systems where users can control iSCSI initiator operations, including containerized environments where storage connectivity is managed dynamically.

Detection Methods for CVE-2026-23296

Indicators of Compromise

• System logs showing scsi_alloc_sdev: Allocation failure during SCSI scanning messages
• The iscsid daemon becoming unresponsive or entering an uninterruptible sleep state
• Processes stuck in scsi_remove_host visible in kernel stack traces
• Increasing memory consumption in kernel slab allocations related to SCSI

Detection Strategies

• Monitor for processes in uninterruptible sleep state with stack traces containing scsi_remove_host or __wait_for_common
• Implement kernel debugging to track tagset_refcnt values and detect leaks
• Use kernel tracing tools (ftrace, perf) to monitor SCSI subsystem reference count operations
• Deploy SentinelOne Singularity to detect anomalous kernel behavior patterns

Monitoring Recommendations

• Configure alerts for iscsid process state changes or hangs
• Monitor kernel memory allocations in SCSI-related slab caches
• Implement periodic health checks for iSCSI session state
• Track kernel log patterns indicating SCSI allocation failures

How to Mitigate CVE-2026-23296

Immediate Actions Required

• Apply the latest kernel patches from your distribution's security repository
• Minimize unnecessary iSCSI session creation and destruction cycles
• Monitor affected systems for signs of hangs or unresponsive storage daemons
• Consider temporarily disabling automatic iSCSI reconnection if experiencing issues

Patch Information

The Linux kernel maintainers have released fixes across multiple stable branches. The patches are available through the following kernel git commits:

• Commit 1ac22c8eae81
• Commit 7c01b680beaf
• Commit 944a333c8e4d
• Commit 9f5e4abed924
• Commit a03d96598d39
• Commit ec5c17c687b1

System administrators should update to the latest stable kernel version that includes these fixes. For enterprise Linux distributions, check with your vendor for backported security patches.

Workarounds

• Reduce the frequency of iSCSI session disconnections and reconnections
• Implement session persistence configurations to minimize teardown operations
• Schedule periodic system reboots during maintenance windows to clear accumulated leaked references
• Use alternative storage protocols (FC, NVMe-oF) where iSCSI is not strictly required

# Check for stuck iscsid processes
ps aux | grep iscsid

# Monitor kernel messages for SCSI allocation failures
dmesg | grep -i "scsi_alloc_sdev"

# View stack traces of stuck processes
cat /proc/$(pidof iscsid)/stack

# Restart iSCSI services if safe to do so
systemctl restart iscsid