Executive Summary
| Informations | |||
|---|---|---|---|
| Name | CVE-2023-53064 | First vendor Publication | 2025-05-02 |
| Vendor | Cve | Last vendor Modification | 2025-05-02 |
Security-Database Scoring CVSS v3
| Cvss vector : N/A | |||
|---|---|---|---|
| Overall CVSS Score | NA | ||
| Base Score | NA | Environmental Score | NA |
| impact SubScore | NA | Temporal Score | NA |
| Exploitabality Sub Score | NA | ||
| Calculate full CVSS 3.0 Vectors scores | |||
Security-Database Scoring CVSS v2
| Cvss vector : | |||
|---|---|---|---|
| Cvss Base Score | N/A | Attack Range | N/A |
| Cvss Impact Score | N/A | Attack Complexity | N/A |
| Cvss Expoit Score | N/A | Authentication | N/A |
| Calculate full CVSS 2.0 Vectors scores | |||
Detail
| In the Linux kernel, the following vulnerability has been resolved: iavf: fix hang on reboot with ice When a system with E810 with existing VFs gets rebooted the following hang may be observed. Pid 1 is hung in iavf_remove(), part of a network driver: During reboot all drivers PM shutdown callbacks are invoked. In iavf_shutdown() the adapter state is changed to __IAVF_REMOVE. In ice_shutdown() the call chain above is executed, which at some point calls iavf_remove(). However iavf_remove() expects the VF to be in one of the states __IAVF_RUNNING, __IAVF_DOWN or __IAVF_INIT_FAILED. If that's not the case it sleeps forever. So if iavf_shutdown() gets invoked before iavf_remove() the system will hang indefinitely because the adapter is already in state __IAVF_REMOVE. Fix this by returning from iavf_remove() if the state is __IAVF_REMOVE, as we already went through iavf_shutdown(). |
Original Source
| Url : http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-53064 |
Sources (Detail)
Alert History
| Date | Informations |
|---|---|
| 2025-05-27 02:29:51 |
|
