CVE-2026-45997

What it actually does

This is a local Linux kernel availability flaw in the SCSI disk driver error-handling path. When adding a SCSI disk device fails during probing, the kernel releases the scsi_disk object but does not drop the associated gendisk reference with put_disk(). That mismatch can leave kernel block-device state in an inconsistent or leaked-reference condition. Repeatedly triggering the failing device-add path can consume kernel resources or destabilize the block subsystem, potentially leading to kernel warnings, hangs, or a local denial of service. The flaw does not provide confidentiality or integrity impact by itself and requires local privileges or local ability to influence SCSI/block-device enumeration.

Why it matters to the business

Successful exploitation can interrupt availability of Linux systems by destabilizing storage-device handling or exhausting kernel resources. Impact is most relevant for servers, virtualization hosts, build systems, appliances, and endpoints where local users, containers with device-management privileges, or automation can trigger block-device hotplug/probe activity. The issue is not listed in CISA KEV, is not known to be used in ransomware campaigns, and has very low EPSS at this time, so broad internet-scale exploitation is unlikely; however, systems with untrusted local users or delegated device-management workflows should still prioritize kernel updates during normal maintenance.

How an attack unfolds

An attacker first needs local access with enough privilege or capability to influence SCSI disk discovery, hotplug, or device creation paths. They then cause the kernel to attempt to add a SCSI disk while forcing device_add() to fail, such as by repeatedly creating/removing virtual or physical SCSI-like block devices under constrained or error-inducing conditions. In the vulnerable kernel path, the failed add operation releases the SCSI disk object but does not release the related gendisk reference. By repeating this sequence, the attacker may accumulate leaked kernel references or inconsistent block-device state. The practical result is a local denial of service, visible as kernel errors, degraded storage handling, resource exhaustion, or system instability. There is no indication of public exploit maturity or active exploitation in known threat campaigns.

How to fix it

Upgrade to a Linux kernel version that includes the upstream fix for the SCSI sd driver cleanup path. No exact fixed package versions were provided in the input, so use the latest security-supported kernel from the operating system or appliance vendor and confirm the vendor advisory explicitly references this fix or includes the upstream SCSI sd put_disk() cleanup change. Reboot into the updated kernel after installation. Where immediate patching is not possible, reduce exposure by limiting local shell access, restricting users who can attach or manage block devices, disabling unnecessary hotplug paths, limiting container/device passthrough privileges, and monitoring for abnormal SCSI/block-device add failures or kernel warnings.

How to confirm the fix worked

Confirm the system is running a patched kernel, not merely that the package is installed. On Linux systems, compare the active kernel from uname -r with the vendor-fixed kernel version or advisory. Review package manager history to ensure the kernel update was installed and the host rebooted into it. If building kernels internally, verify the SCSI sd driver code includes the cleanup change that calls put_disk(gd) when device_add(&sdkp->disk_dev) fails. Validate exposure reduction by checking that untrusted users and containers cannot attach arbitrary block devices or manage SCSI/USB-storage passthrough unless required.

Typical attack path

1. Obtain local access to a Linux system, or access to a context that can influence block-device/SCSI disk enumeration.
2. Trigger SCSI disk probe activity, for example through hotplug, virtual device attachment, removable storage, or privileged device-management operations.
3. Induce or rely on failure of device_add() during the SCSI disk add path.
4. Repeat the failure path so the missing put_disk() cleanup leaves stale gendisk references or leaked kernel resources.
5. Cause storage subsystem degradation, kernel warnings, hangs, or system denial of service.

How to detect it

There are no reliable network indicators for this vulnerability because exploitation is local and occurs inside the kernel SCSI disk probe path. To assess possible prior exploitation, review kernel logs from dmesg, journalctl -k, /var/log/kern.log, /var/log/messages, and crash/panic records for repeated SCSI disk add/probe failures followed by kernel warnings, oopses, hangs, or reboots. Correlate these events with auditd, sudo, udev, virtualization, container runtime, and removable-device logs to identify users or processes repeatedly attaching/removing block devices or invoking privileged device-management operations. Investigate bursts of device hotplug activity, failed disk registration, unexplained memory/resource exhaustion, storage subsystem instability, and local sessions active immediately before crashes. Since normal hardware failure can produce similar symptoms, prioritize patterns that are repeated, user-correlated, and temporally close to kernel instability.

• sd_probe
• scsi_disk_release
• device_add(&sdkp->disk_dev)
• device_add_disk
• put_disk(gd)
• scsi: sd:
• Kernel panic
• kernel BUG
• general protection fault
• WARNING: CPU:
• Oops:
• blocked for more than 120 seconds
• udevd
• systemd-udevd
• add disk failed
• failed to add disk
• SCSI disk
• gendisk

What your security team should do

• Patch affected Linux kernels through normal kernel security update channels and reboot systems into the fixed kernel.
• Prioritize systems with untrusted local users, shared shell access, virtualization/container workloads, removable media, or device passthrough.
• Restrict local users, containers, and automation from managing SCSI, USB mass-storage, loop, or other block-device hotplug paths unless operationally required.
• Harden container and virtualization configurations to avoid unnecessary --privileged mode, broad /dev passthrough, CAP_SYS_ADMIN, and host device management access.
• Monitor kernel logs for repeated SCSI disk probe failures, device_add failures, block-device registration errors, and kernel oops/panic events.
• Because there is no KEV listing, ransomware association, or known exploit maturity, treat this as a defense-in-depth local DoS fix unless local multi-user exposure increases risk.