# CVE-2023-53245: scsi: storvsc: Fix handling of virtual Fibre Channel timeouts > A null pointer dereference in the Linux kernel's storvsc driver causes a system panic during virtual Fibre Channel timeouts, leading to denial of service. - **Severity:** Medium 5.5 (`CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H`) - **Exploited in the wild:** Not known - **Login needed:** Any signed-in user - **Attackable:** Local or same network only - **Victim action needed:** Not needed - **Fix available:** Yes - **Published:** 15 Sep 2025 - **Updated:** 11 May 2026 - **Also known as:** BELL-CVE-2023-53245, DEBIAN-CVE-2023-53245, GHSA-3xmr-hc67-565w, UBUNTU-CVE-2023-53245 ## What is CVE-2023-53245? CVE-2023-53245 is a medium-severity vulnerability in Linux kernel, published on 15 Sep 2025. It can only be exploited from the same machine or local network, with no action from the victim. ### Official 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. Weakness: CWE-476 (NULL Pointer Dereference) ## Which versions are affected by CVE-2023-53245? It affects 1 product. Products: Linux kernel. ## How do I fix CVE-2023-53245? Apply the vendor's patch. ## Is CVE-2023-53245 being exploited? There is no known exploitation of CVE-2023-53245 in the wild and no public exploit code. ## Other vulnerabilities in Linux kernel - [CVE-2026-53266](https://insights.sbomify.com/CVE-2026-53266/): Linux Kernel Out-of-Bounds Write (high 8.8, exploited in the wild) - [CVE-2013-6282](https://insights.sbomify.com/CVE-2013-6282/): Linux Kernel Improper Input Validation (high 8.8, exploited in the wild) - [CVE-2022-0185](https://insights.sbomify.com/CVE-2022-0185/): Linux Kernel Heap-Based Buffer Overflow (high 8.4, exploited in the wild) - [CVE-2013-2094](https://insights.sbomify.com/CVE-2013-2094/): Linux Kernel Privilege Escalation (high 8.4, exploited in the wild) - [CVE-2026-53362](https://insights.sbomify.com/CVE-2026-53362/): Linux Kernel Unspecified (high 7.8, exploited in the wild) ## Fix prompt for AI coding agents ```text Check this codebase for CVE-2023-53245 and fix it if it is affected. What it is: CVE-2023-53245 is a medium-severity vulnerability in Linux kernel, published on 15 Sep 2025. It can only be exploited from the same machine or local network, with no action from the victim. Exploitation: There is no known exploitation of CVE-2023-53245 in the wild and no public exploit code. Affected product: Linux kernel. No package-level version data is available, so check the vendor advisory linked from the reference page. Task: 1. Search the dependency manifests and lockfiles (for example package.json, package-lock.json, requirements.txt, poetry.lock, uv.lock, pom.xml, build.gradle, go.mod, Cargo.lock, Gemfile.lock) and any Dockerfiles for the affected packages, including transitive dependencies. 2. If an affected version is in use, upgrade it to the fixed version for its release line with the project's package manager, so the lockfile is regenerated. Prefer the smallest upgrade that fixes it. 3. If there is no fix, or the upgrade would break the build, do not guess: explain the risk and the safest workaround instead. 4. Run the tests and summarise what changed and why. 5. If nothing in the project is affected, say so and change nothing. Reference: https://insights.sbomify.com/CVE-2023-53245/ (Markdown: https://insights.sbomify.com/CVE-2023-53245/index.md) ``` ## Sources - CVE record: https://www.cve.org/CVERecord?id=CVE-2023-53245 - NVD: https://nvd.nist.gov/vuln/detail/CVE-2023-53245 - OSV: https://osv.dev/vulnerability/CVE-2023-53245 --- From sbomify Insights: https://insights.sbomify.com/CVE-2023-53245/ Summaries are generated and may contain mistakes; the official description above is the record.