CVE-2022-48862
- Source
- https://nvd.nist.gov/vuln/detail/CVE-2022-48862
- Import Source
- https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2022-48862.json
- JSON Data
- https://api.osv.dev/v1/vulns/CVE-2022-48862
- Downstream
- Related
- Published
- 2024-07-16T13:15:13Z
- Modified
- 2025-08-09T19:01:27Z
- Severity
-
- 5.5 (Medium) CVSS_V3 - CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H CVSS Calculator
- Summary
- [none]
- Details
-
In the Linux kernel, the following vulnerability has been resolved:
vhost: fix hung thread due to erroneous iotlb entries
In vhostiotlbaddrangectx(), range size can overflow to 0 when start is 0 and last is ULONGMAX. One instance where it can happen is when userspace sends an IOTLB message with iova=size=uaddr=0 (vhostprocessiotlbmsg). So, an entry with size = 0, start = 0, last = ULONGMAX ends up in the iotlb. Next time a packet is sent, iotlbaccess_ok() loops indefinitely due to that erroneous entry.
Call Trace: <TASK> iotlb_access_ok+0x21b/0x3e0 drivers/vhost/vhost.c:1340 vq_meta_prefetch+0xbc/0x280 drivers/vhost/vhost.c:1366 vhost_transport_do_send_pkt+0xe0/0xfd0 drivers/vhost/vsock.c:104 vhost_worker+0x23d/0x3d0 drivers/vhost/vhost.c:372 kthread+0x2e9/0x3a0 kernel/kthread.c:377 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:295 </TASK>Reported by syzbot at: https://syzkaller.appspot.com/bug?extid=0abd373e2e50d704db87
To fix this, do two things:
- Return -EINVAL in vhostchrwrite_iter() when userspace asks to map a range with size 0.
- Fix vhostiotlbaddrangectx() to handle the range [0, ULONG_MAX] by splitting it into two entries.
- References