CVE-2026-43475

What it actually does

This flaw is a Linux kernel availability issue in the Hyper-V SCSI storage driver, hv_storvsc/storvsc, when the kernel is built or running with PREEMPT_RT real-time preemption enabled. Under local I/O activity, storvsc_queuecommand can attempt an operation that may sleep while execution is in an atomic/preemption-disabled context, triggering a kernel "scheduling while atomic" condition. On affected Hyper-V virtual machines, this can result in kernel warnings, stalled storage I/O, or a system lock-up. The impact is availability only; the provided CVSS vector indicates local, low-complexity exploitation requiring local privileges, with no confidentiality or integrity impact.

Why it matters to the business

Organizations running Linux real-time kernels on Hyper-V may experience VM hangs or storage-related outages if a local user or workload triggers the vulnerable code path through disk I/O. The most likely consequence is service disruption, failed jobs, delayed processing, or the need to reboot affected systems. Because this is not in CISA KEV, has very low EPSS, and has no known public exploit maturity in the supplied data, broad internet-scale exploitation is unlikely; however, critical real-time or latency-sensitive workloads using Hyper-V storage should treat it as an operational stability risk.

How an attack unfolds

An attacker must first have local ability to run code or otherwise generate disk I/O on an affected Linux guest. The target system must be using the Hyper-V storvsc storage path and PREEMPT_RT must be enabled. The attacker then generates sufficient read/write activity, such as repeated filesystem writes or I/O stress, to drive SCSI requests through storvsc_queuecommand. When the vulnerable path is hit, the driver may attempt to acquire a sleeping RT lock or send through the Hyper-V VMBus ring buffer while preemption is disabled. The kernel detects scheduling while atomic and the VM may lock up or become unresponsive, causing a denial of service. There is no indication from the supplied data that this flaw enables privilege escalation, data theft, or remote unauthenticated compromise.

How to fix it

Apply the Linux kernel update that includes the storvsc PREEMPT_RT scheduling fix for the distribution and kernel stream in use. No exact fixed package versions were provided, so administrators should consult their Linux distribution, cloud image, or kernel vendor advisories for CVE-2026-43475 and deploy the corrected kernel. After updating, reboot into the fixed kernel and verify the running kernel version, because kernel package installation alone does not remediate until the host is running the patched kernel. Where immediate patching is not possible, reduce exposure by avoiding PREEMPT_RT kernels on affected Hyper-V guests where real-time behavior is not required, limiting local shell or workload execution to trusted users, isolating untrusted workloads, and monitoring/restarting affected VMs if storage stalls occur. For high-availability services, fail workloads over before patching to avoid unplanned downtime.

How to confirm the fix worked

Confirm exposure by checking whether the system is a Linux guest using Hyper-V storage modules such as hv_storvsc and whether PREEMPT_RT is enabled in the running kernel configuration. Validate remediation by confirming the machine has rebooted into a vendor kernel version that contains the storvsc fix, then review kernel logs for absence of new "BUG: scheduling while atomic" events involving storvsc_queuecommand, hv_ringbuffer_write, vmbus_sendpacket_mpb_desc, or hv_storvsc during normal and representative storage I/O. In test environments, run controlled disk I/O stress against a patched Hyper-V guest with PREEMPT_RT enabled and verify the VM remains responsive and no relevant kernel splats are emitted. Do not use destructive stress testing on production systems without change control and rollback plans.

Typical attack path

1. Gain local access to an affected Linux virtual machine, or obtain the ability to run a workload that performs disk I/O.
2. Confirm or rely on the system using the Hyper-V SCSI storage driver, typically hv_storvsc, with PREEMPT_RT enabled.
3. Generate sustained filesystem or block-device I/O, for example repeated writes, reads, or I/O stress workloads.
4. Trigger the vulnerable storvsc_queuecommand path during SCSI request submission.
5. Cause a kernel "scheduling while atomic" condition that may stall storage I/O or lock up the virtual machine.
6. Wait for service degradation, watchdog intervention, or administrative reboot/recovery.

How to detect it

To determine whether this issue may already have been triggered, review kernel and system logs from affected Linux Hyper-V guests, including journalctl -k, /var/log/kern.log, /var/log/messages, /var/log/syslog, persistent pstore records, crash dumps, and hypervisor/VM availability telemetry. Search for kernel splats containing "BUG: scheduling while atomic" with call traces that include storvsc_queuecommand, hv_storvsc, hv_ringbuffer_write, vmbus_sendpacket_mpb_desc, scsi_queue_rq, or blk_mq functions. Correlate these events with local user sessions, cron jobs, containers, batch workloads, backup jobs, database maintenance, or I/O stress tools that were active immediately beforehand. Also look for sudden VM lockups, storage timeouts, watchdog resets, unexpected reboots, or gaps in telemetry following the kernel message. These artifacts indicate the vulnerable condition was likely reached, but they are not proof of malicious exploitation because ordinary high-I/O workloads can trigger the same failure mode.

• BUG: scheduling while atomic
• storvsc_queuecommand
• hv_storvsc
• hv_ringbuffer_write
• vmbus_sendpacket_mpb_desc
• schedule_rtlock
• rtlock_slowlock_locked
• rt_spin_lock
• scsi_queue_rq
• blk_mq_issue_direct
• blk_mq_dispatch_queue_requests
• Preemption disabled at:
• PREEMPT_RT
• stress-ng-iomix
• Modules linked in:
• /var/log/kern.log
• /var/log/messages
• /var/log/syslog
• /sys/fs/pstore/

What your security team should do

• Prioritize inventory of Linux VMs running on Hyper-V with PREEMPT_RT or real-time kernel variants enabled.
• Patch and reboot affected real-time Hyper-V Linux guests using the vendor-provided kernel update as soon as operationally practical, prioritizing production systems with heavy storage I/O.
• If real-time preemption is not required, consider moving affected workloads to a non-PREEMPT_RT kernel until the fixed RT kernel is available and deployed.
• Restrict local interactive access and untrusted workload execution on exposed systems, because exploitation requires local privileges or the ability to generate local I/O.
• Add monitoring for kernel log messages indicating "scheduling while atomic" in hv_storvsc/storvsc paths and alert on repeated storage-driver splats or VM responsiveness failures.
• Coordinate patching with service owners because the remediation requires booting into a fixed kernel and may require planned downtime or workload failover.
• Because KEV is false, ransomware use is not indicated, EPSS is very low, and exploit maturity is listed as none, handle this as a targeted availability/stability risk rather than an emergency internet-facing remote code execution event.