Skip to main content

Linux Kernel EUVDEUVD-2026-45576

| CVE-2026-64003 HIGH
2026-07-19 Linux GHSA-rqvx-8pr4-6wfh
Information Disclosure Linux
High
Disputed · 7.5 Vendor: Linux
Share

Severity by source

Sources disagree (Low–High)
Vendor (Linux) PRIMARY
7.5 HIGH
AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
vuln.today AI
4.1 MEDIUM

Triggering requires local privileged storage teardown/error-recovery activity with specific timing (AV:L, PR:H, AC:H); impact is a hung removal so availability-only (A:H), no C/I effect.

3.1 AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:H
4.0 AV:L/AC:H/AT:P/PR:H/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
SUSE
HIGH
qualitative
Red Hat
5.5 LOW
qualitative

vuln.today treats the vendor’s rating as authoritative. A higher third-party CVSS (e.g. CISA-ADP) is shown for transparency but does not drive the headline severity.

CVSS VectorVendor: Linux

Attack Vector
Network
Attack Complexity
Low
Privileges Required
None
User Interaction
None
Scope
Unchanged
Confidentiality
None
Integrity
None
Availability
High

Lifecycle Timeline

5
Analysis Generated
Jul 20, 2026 - 16:46 vuln.today
CVSS changed
Jul 20, 2026 - 15:22 NVD
7.5 (HIGH)
Patch available
Jul 19, 2026 - 17:19 EUVD
CVE Published
Jul 19, 2026 - 14:56 cve.org
HIGH 7.5
CVE Published
Jul 19, 2026 - 14:56 cve.org
UNKNOWN (no severity yet)

DescriptionCVE.org

In the Linux kernel, the following vulnerability has been resolved:

scsi: core: Run queues for all non-SDEV_DEL devices from scsi_run_host_queues

While a SCSI host is in a recovery state, scsi_mq_requeue_cmd() will not set the requeue list for a requeued command to be kicked in the future. The expectation is a call to scsi_run_host_queues() will kick all SCSI devices once the recovery state is cleared.

However, scsi_run_host_queues() uses shost_for_each_device() which uses scsi_device_get() and so will ignore devices in a partially removed state like SDEV_CANCEL. But these devices may also have requeued requests, leaving their requests stuck from not being kicked and causing the removal process of the device to hang.

scsi_run_host_queues() needs to run against more devices than the macro shost_for_each_device() allows. Instead of using the too limiting scsi_device_get() state checks, only ignore devices in SDEV_DEL state or when unable to acquire a reference. Attempt to run the queues for all other devices when scsi_run_host_queues() is called.

AnalysisAI

Denial of service in the Linux kernel SCSI core allows a device removal process to hang when SCSI devices in a partially-removed state (SDEV_CANCEL) retain requeued requests that are never kicked. Because scsi_run_host_queues() relied on shost_for_each_device()/scsi_device_get(), which skips devices not in a runnable state, requests queued during host error recovery stayed stuck after recovery cleared. The fix broadens scsi_run_host_queues() to run queues for every device except those in SDEV_DEL or where a reference cannot be acquired. No public exploit identified at time of analysis; EPSS is low (0.17%, 6th percentile).

Technical ContextAI

The affected component is the SCSI mid-layer (scsi: core) in the Linux kernel's block/SCSI request handling path. During SCSI host error recovery, scsi_mq_requeue_cmd() places commands on a requeue list but intentionally does not immediately re-run the queue; the design contract is that scsi_run_host_queues() will later kick all devices once the recovery/host state clears. The root cause is an iteration/state-filtering defect: shost_for_each_device() uses scsi_device_get(), which refuses references to devices not in a fully live state, so devices transitioning through SDEV_CANCEL (part of the removal lifecycle) are silently skipped even though they may hold requeued I/O. No CWE was assigned, but this maps to an incorrect-state-check / improper resource-lifecycle handling class leading to stalled I/O. Affected code spans stable trees including 6.6.x, 6.12.x, 6.18.x and 7.x per the kernel stable commits.

RemediationAI

Vendor-released patch: update to a fixed stable kernel - 6.6.143, 6.12.93, 6.18.35, 7.0.12 or 7.1 (or later within your branch) - sourced from your distribution's kernel updates or directly from the kernel stable commits at git.kernel.org (e.g. https://git.kernel.org/stable/c/475f2b37a78f4c698967a7f14f325f04e24c9175). Apply via your distro's normal kernel package update and reboot. No practical in-kernel workaround exists for the underlying requeue/removal race short of the patch; as an operational mitigation, avoid SCSI device hot-removal or hostile conditions that force host error recovery on unpatched systems, accepting that this only reduces the trigger window rather than eliminating the bug. Because impact is a stuck removal (availability), scheduling the patch in a routine maintenance window is appropriate.

Same technique Information Disclosure

View all
CVE-2019-2725 CRITICAL POC
9.8
CVE-2021-34523 CRITICAL POC
9.0
CVE-2013-2251 CRITICAL POC
9.8
CVE-2017-5638 CRITICAL POC
9.8
CVE-2025-24813 CRITICAL POC
9.8
CVE-2015-1701 HIGH POC
7.8
CVE-2017-0147 HIGH POC
7.5
CVE-2014-6324 HIGH POC
8.8

Vendor StatusVendor

SUSE

Severity: Important
Product Status
SUSE Linux Enterprise Desktop 15 SP7 Affected
SUSE Linux Enterprise Desktop 15 SP7 Affected
SUSE Linux Enterprise High Availability Extension 15 SP7 Affected
SUSE Linux Enterprise High Availability Extension 15 SP7 Affected
SUSE Linux Enterprise High Availability Extension 16.0 Affected

Share

EUVD-2026-45576 vulnerability details – vuln.today
Back

This site uses cookies essential for authentication and security. No tracking or analytics cookies are used. Privacy Policy