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 |
|