CVE-2022-48862
published 2024-07-16CVE-2022-48862: 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…
PriorityP419medium5.5CVSS 3.1
AVLACLPRLUINSUCNINAH
EPSS
0.21%
11.0th percentile
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:
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
Reported by syzbot at:
https://syzkaller.appspot.com/bug?extid=0abd373e2e50d704db87
To fix this, do two things:
1. Return -EINVAL in vhost_chr_write_iter() when userspace asks to map
a range with size 0.
2. Fix vhost_iotlb_add_range_ctx() to handle the range [0, ULONG_MAX]
by splitting it into two entries.
Affected
10 ranges
| Vendor | Product | Version range | Fixed in |
|---|---|---|---|
| debian | linux | < linux 5.16.18-1 (bookworm) | linux 5.16.18-1 (bookworm) |
| linux | linux | — | — |
| linux | linux | >= 0bbe30668d89ec8a309f28ced6d092c90fb23e8c < f8d88e86e90ea1002226d7ac2430152bfea003d1 | f8d88e86e90ea1002226d7ac2430152bfea003d1 |
| linux | linux | >= 0bbe30668d89ec8a309f28ced6d092c90fb23e8c < d9a747e6b6561280bf1791bb24c5e9e082193dad | d9a747e6b6561280bf1791bb24c5e9e082193dad |
| linux | linux | >= 0bbe30668d89ec8a309f28ced6d092c90fb23e8c < e2ae38cf3d91837a493cb2093c87700ff3cbe667 | e2ae38cf3d91837a493cb2093c87700ff3cbe667 |
| linux | linux_kernel | >= 0 < 5.16.18-1 | 5.16.18-1 |
| linux | linux_kernel | >= 0 < 5.16.18-1 | 5.16.18-1 |
| linux | linux_kernel | >= 0 < 5.16.18-1 | 5.16.18-1 |
| linux | linux_kernel | >= 5.16 < 5.16.15 | 5.16.15 |
| linux | linux_kernel | >= 5.7 < 5.15.29 | 5.15.29 |
CVSS provenance
nvdv3.15.5MEDIUMCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
osv5.5MEDIUM
vendor_debian5.5MEDIUM
vendor_redhat5.5MEDIUM
Stop checking back — get the weekly exploitation signal.
Every Monday: what got weaponized or added to CISA KEV in the last seven days — each CVE cross-linked to its PoC, Nuclei template, and detection rule. Free, one email a week, unsubscribe in one click.
Red Hat
kernel: vhost: fix hung thread due to erroneous iotlb entries
vendor_redhat·2024-07-16·CVSS 5.5
CVE-2022-48862 [MEDIUM] CWE-835 kernel: vhost: fix hung thread due to erroneous iotlb entries
kernel: vhost: fix hung thread due to erroneous iotlb entries
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:
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 driver
Debian
CVE-2022-48862: linux - In the Linux kernel, the following vulnerability has been resolved: vhost: fix ...
vendor_debian·2022·CVSS 5.5
CVE-2022-48862 [MEDIUM] CVE-2022-48862: linux - In the Linux kernel, the following vulnerability has been resolved: vhost: fix ...
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: 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
OSV
CVE-2022-48862: 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
osv·2024-07-16·CVSS 5.5
CVE-2022-48862 [MEDIUM] CVE-2022-48862: 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
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: 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
GHSA
GHSA-cqc3-8mfm-84p4: In the Linux kernel, the following vulnerability has been resolved:
vhost: fix hung thread due to erroneous iotlb entries
In vhost_iotlb_add_range_c
ghsa_unreviewed·2024-07-16
CVE-2022-48862 [MEDIUM] CWE-835 GHSA-cqc3-8mfm-84p4: In the Linux kernel, the following vulnerability has been resolved:
vhost: fix hung thread due to erroneous iotlb entries
In vhost_iotlb_add_range_c
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:
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
No detection rules found.
No public exploits indexed.
No writeups or analysis indexed.
https://git.kernel.org/stable/c/d9a747e6b6561280bf1791bb24c5e9e082193dadhttps://git.kernel.org/stable/c/e2ae38cf3d91837a493cb2093c87700ff3cbe667https://git.kernel.org/stable/c/f8d88e86e90ea1002226d7ac2430152bfea003d1https://git.kernel.org/stable/c/d9a747e6b6561280bf1791bb24c5e9e082193dadhttps://git.kernel.org/stable/c/e2ae38cf3d91837a493cb2093c87700ff3cbe667https://git.kernel.org/stable/c/f8d88e86e90ea1002226d7ac2430152bfea003d1
2024-07-16
Published