CVE-2023-53245
Unknown Unknown - Not Provided
BaseFortify

Publication date: 2025-09-15

Last updated on: 2025-12-03

Assigner: kernel.org

Description
In the Linux kernel, the following vulnerability has been resolved: scsi: storvsc: Fix handling of virtual Fibre Channel timeouts Hyper-V provides the ability to connect Fibre Channel LUNs to the host system and present them in a guest VM as a SCSI device. I/O to the vFC device is handled by the storvsc driver. The storvsc driver includes a partial integration with the FC transport implemented in the generic portion of the Linux SCSI subsystem so that FC attributes can be displayed in /sys. However, the partial integration means that some aspects of vFC don't work properly. Unfortunately, a full and correct integration isn't practical because of limitations in what Hyper-V provides to the guest. In particular, in the context of Hyper-V storvsc, the FC transport timeout function fc_eh_timed_out() causes a kernel panic because it can't find the rport and dereferences a NULL pointer. The original patch that added the call from storvsc_eh_timed_out() to fc_eh_timed_out() is faulty in this regard. In many cases a timeout is due to a transient condition, so the situation can be improved by just continuing to wait like with other I/O requests issued by storvsc, and avoiding the guaranteed panic. For a permanent failure, continuing to wait may result in a hung thread instead of a panic, which again may be better. So fix the panic by removing the storvsc call to fc_eh_timed_out(). This allows storvsc to keep waiting for a response. The change has been tested by users who experienced a panic in fc_eh_timed_out() due to transient timeouts, and it solves their problem. In the future we may want to deprecate the vFC functionality in storvsc since it can't be fully fixed. But it has current users for whom it is working well enough, so it should probably stay for a while longer.
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2025-09-15
Last Modified
2025-12-03
Generated
2026-05-07
AI Q&A
2025-09-15
EPSS Evaluated
2026-05-05
NVD
Affected Vendors & Products
Showing 12 associated CPEs
Vendor Product Version / Range
linux linux_kernel From 4.13 (inc) to 4.14.323 (exc)
linux linux_kernel From 4.15 (inc) to 4.19.292 (exc)
linux linux_kernel From 4.20 (inc) to 5.4.254 (exc)
linux linux_kernel From 5.5 (inc) to 5.10.191 (exc)
linux linux_kernel From 5.11 (inc) to 5.15.127 (exc)
linux linux_kernel From 5.16 (inc) to 6.1.46 (exc)
linux linux_kernel From 6.2 (inc) to 6.4.11 (exc)
linux linux_kernel 6.5
linux linux_kernel 6.5
linux linux_kernel 6.5
linux linux_kernel 6.5
linux linux_kernel 6.5
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-476 The product dereferences a pointer that it expects to be valid but is NULL.
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?

This vulnerability is in the Linux kernel's storvsc driver, which handles virtual Fibre Channel (vFC) devices presented by Hyper-V to guest VMs as SCSI devices. The issue arises because the storvsc driver partially integrates with the Fibre Channel transport in the Linux SCSI subsystem, but this integration is incomplete due to Hyper-V limitations. Specifically, when a Fibre Channel transport timeout occurs, the function fc_eh_timed_out() is called and causes a kernel panic by dereferencing a NULL pointer because it cannot find the remote port (rport). The original patch that linked storvsc's timeout handler to fc_eh_timed_out() was faulty. The fix removes this call, allowing storvsc to continue waiting for a response instead of panicking, which prevents the kernel panic and improves stability during transient timeouts.


How can this vulnerability impact me? :

This vulnerability can cause a kernel panic in systems using Hyper-V virtual Fibre Channel devices with the storvsc driver in the Linux kernel. A kernel panic leads to a system crash, causing downtime and potential data loss or service interruption. By triggering a panic during Fibre Channel timeouts, the system becomes unstable under certain I/O conditions, especially transient timeouts. The fix prevents the panic by allowing the system to wait longer instead of crashing, improving system reliability.


What immediate steps should I take to mitigate this vulnerability?

To mitigate this vulnerability, update the Linux kernel to a version where the storvsc driver has been fixed to remove the call to fc_eh_timed_out(), preventing kernel panic on virtual Fibre Channel timeouts. This fix allows the system to continue waiting for a response instead of panicking. If updating is not immediately possible, consider avoiding use of the vFC functionality in storvsc as it may cause instability.


Ask Our AI Assistant
Need more information? Ask your question to get an AI reply (Powered by our expertise)
0/70
EPSS Chart