CVE-2023-53245

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: storvsc: Fix handling of virtual Fibre Channel timeouts<br /> <br /> Hyper-V provides the ability to connect Fibre Channel LUNs to the host<br /> system and present them in a guest VM as a SCSI device. I/O to the vFC<br /> device is handled by the storvsc driver. The storvsc driver includes a<br /> partial integration with the FC transport implemented in the generic<br /> portion of the Linux SCSI subsystem so that FC attributes can be displayed<br /> in /sys. However, the partial integration means that some aspects of vFC<br /> don&amp;#39;t work properly. Unfortunately, a full and correct integration isn&amp;#39;t<br /> practical because of limitations in what Hyper-V provides to the guest.<br /> <br /> In particular, in the context of Hyper-V storvsc, the FC transport timeout<br /> function fc_eh_timed_out() causes a kernel panic because it can&amp;#39;t find the<br /> rport and dereferences a NULL pointer. The original patch that added the<br /> call from storvsc_eh_timed_out() to fc_eh_timed_out() is faulty in this<br /> regard.<br /> <br /> In many cases a timeout is due to a transient condition, so the situation<br /> can be improved by just continuing to wait like with other I/O requests<br /> issued by storvsc, and avoiding the guaranteed panic. For a permanent<br /> failure, continuing to wait may result in a hung thread instead of a panic,<br /> which again may be better.<br /> <br /> So fix the panic by removing the storvsc call to fc_eh_timed_out(). This<br /> allows storvsc to keep waiting for a response. The change has been tested<br /> by users who experienced a panic in fc_eh_timed_out() due to transient<br /> timeouts, and it solves their problem.<br /> <br /> In the future we may want to deprecate the vFC functionality in storvsc<br /> since it can&amp;#39;t be fully fixed. But it has current users for whom it is<br /> working well enough, so it should probably stay for a while longer.