Executive Summary
| Informations | |||
|---|---|---|---|
| Name | CVE-2022-48862 | First vendor Publication | 2024-07-16 |
| Vendor | Cve | Last vendor Modification | 2024-07-23 |
Security-Database Scoring CVSS v3
| Cvss vector : CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H | |||
|---|---|---|---|
| Overall CVSS Score | 5.5 | ||
| Base Score | 5.5 | Environmental Score | 5.5 |
| impact SubScore | 3.6 | Temporal Score | 5.5 |
| Exploitabality Sub Score | 1.8 | ||
| Attack Vector | Local | Attack Complexity | Low |
| Privileges Required | Low | User Interaction | None |
| Scope | Unchanged | Confidentiality Impact | None |
| Integrity Impact | None | Availability Impact | High |
| 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: vhost: fix hung thread due to erroneous iotlb entries In vhost_iotlb_add_range_ctx(), range size can overflow to 0 when start is 0 and last is ULONG_MAX. One instance where it can happen is when userspace sends an IOTLB message with iova=size=uaddr=0 (vhost_process_iotlb_msg). So, an entry with size = 0, start = 0, last = ULONG_MAX ends up in the iotlb. Next time a packet is sent, iotlb_access_ok() loops indefinitely due to that erroneous entry. Call Trace: Reported by syzbot at: To fix this, do two things: 1. Return -EINVAL in vhost_chr_write_iter() when userspace asks to map |
Original Source
| Url : http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-48862 |
CPE : Common Platform Enumeration
Sources (Detail)
Alert History
| Date | Informations |
|---|---|
| 2024-08-22 02:35:06 |
|
| 2024-08-02 13:43:22 |
|
| 2024-08-02 01:31:24 |
|
| 2024-07-23 21:27:32 |
|
| 2024-07-16 17:27:23 |
|
