CVE-2022-48721
published 2024-06-20CVE-2022-48721: In the Linux kernel, the following vulnerability has been resolved: net/smc: Forward wakeup to smc socket waitqueue after fallback When we replace TCP with SMC…
PriorityP420medium5.5CVSS 3.1
AVLACLPRLUINSUCNINAH
EPSS
0.23%
14.1th percentile
In the Linux kernel, the following vulnerability has been resolved:
net/smc: Forward wakeup to smc socket waitqueue after fallback
When we replace TCP with SMC and a fallback occurs, there may be
some socket waitqueue entries remaining in smc socket->wq, such
as eppoll_entries inserted by userspace applications.
After the fallback, data flows over TCP/IP and only clcsocket->wq
will be woken up. Applications can't be notified by the entries
which were inserted in smc socket->wq before fallback. So we need
a mechanism to wake up smc socket->wq at the same time if some
entries remaining in it.
The current workaround is to transfer the entries from smc socket->wq
to clcsock->wq during the fallback. But this may cause a crash
like this:
general protection fault, probably for non-canonical address 0xdead000000000100: 0000 [#1] PREEMPT SMP PTI
CPU: 3 PID: 0 Comm: swapper/3 Kdump: loaded Tainted: G E 5.16.0+ #107
RIP: 0010:__wake_up_common+0x65/0x170
Call Trace:
__wake_up_common_lock+0x7a/0xc0
sock_def_readable+0x3c/0x70
tcp_data_queue+0x4a7/0xc40
tcp_rcv_established+0x32f/0x660
? sk_filter_trim_cap+0xcb/0x2e0
tcp_v4_do_rcv+0x10b/0x260
tcp_v4_rcv+0xd2a/0xde0
ip_protocol_deliver_rcu+0x3b/0x1d0
ip_local_deliver_finish+0x54/0x60
ip_local_deliver+0x6a/0x110
? tcp_v4_early_demux+0xa2/0x140
? tcp_v4_early_demux+0x10d/0x140
ip_sublist_rcv_finish+0x49/0x60
ip_sublist_rcv+0x19d/0x230
ip_list_rcv+0x13e/0x170
__netif_receive_skb_list_core+0x1c2/0x240
netif_receive_skb_list_internal+0x1e6/0x320
napi_complete_done+0x11d/0x190
mlx5e_napi_poll+0x163/0x6b0 [mlx5_core]
__napi_poll+0x3c/0x1b0
net_rx_action+0x27c/0x300
__do_softirq+0x114/0x2d2
irq_exit_rcu+0xb4/0xe0
common_interrupt+0xba/0xe0
The crash is caused by privately transferring waitqueue entries from
smc socket->wq to clcsock->wq. The owners of these entries, such as
epoll, have no idea that the entries have been transferred to a
different socket wait queue and still use original waitqueue spinlock
(smc socket->wq.wait.lock
Affected
27 ranges· showing 25
| Vendor | Product | Version range | Fixed in |
|---|---|---|---|
| debian | linux | < linux 5.16.10-1 (bookworm) | linux 5.16.10-1 (bookworm) |
| linux | linux | — | — |
| linux | linux | — | — |
| linux | linux | — | — |
| linux | linux | >= 2153bd1e3d3dbf6a3403572084ef6ed31c53c5f0 < 504078fbe9dd570d685361b57784a6050bc40aaa | 504078fbe9dd570d685361b57784a6050bc40aaa |
| linux | linux | >= 2153bd1e3d3dbf6a3403572084ef6ed31c53c5f0 < 341adeec9adad0874f29a0a1af35638207352a39 | 341adeec9adad0874f29a0a1af35638207352a39 |
| linux | linux | >= 5.10.84 < 5.11 | 5.11 |
| linux | linux | >= 5.15.7 < 5.15.22 | 5.15.22 |
| linux | linux | >= 5.4.164 < 5.5 | 5.5 |
| linux | linux | >= fb92e025baa73e99250b79ab64f4e088d2888993 < 0ef6049f664941bc0f75828b3a61877635048b27 | 0ef6049f664941bc0f75828b3a61877635048b27 |
| linux | linux_kernel | — | — |
| linux | linux_kernel | — | — |
| linux | linux_kernel | — | — |
| linux | linux_kernel | — | — |
| linux | linux_kernel | — | — |
| linux | linux_kernel | — | — |
| linux | linux_kernel | — | — |
| linux | linux_kernel | — | — |
| linux | linux_kernel | — | — |
| linux | linux_kernel | — | — |
| linux | linux_kernel | >= 0 < 5.16.10-1 | 5.16.10-1 |
| linux | linux_kernel | >= 0 < 5.16.10-1 | 5.16.10-1 |
| linux | linux_kernel | >= 0 < 5.16.10-1 | 5.16.10-1 |
| linux | linux_kernel | >= 5.10.84 < 5.11 | 5.11 |
| linux | linux_kernel | >= 5.15.7 < 5.15.22 | 5.15.22 |
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.
OSV
CVE-2022-48721: In the Linux kernel, the following vulnerability has been resolved: net/smc: Forward wakeup to smc socket waitqueue after fallback When we replace TCP
osv·2024-06-20·CVSS 5.5
CVE-2022-48721 [MEDIUM] CVE-2022-48721: In the Linux kernel, the following vulnerability has been resolved: net/smc: Forward wakeup to smc socket waitqueue after fallback When we replace TCP
In the Linux kernel, the following vulnerability has been resolved: net/smc: Forward wakeup to smc socket waitqueue after fallback When we replace TCP with SMC and a fallback occurs, there may be some socket waitqueue entries remaining in smc socket->wq, such as eppoll_entries inserted by userspace applications. After the fallback, data flows over TCP/IP and only clcsocket->wq will be woken up. Applications can't be notified by the entries which were inserted in smc socket->wq before fallback. So we need a mechanism to wake up smc socket->wq at the same time if some entries remaining in it. The current workaround is to transfer the entries from smc socket->wq to clcsock->wq during the fallback. But this may cause a crash like this: general protection fault, probably for non-canonical addre
GHSA
GHSA-cw8x-f629-7c3v: In the Linux kernel, the following vulnerability has been resolved:
net/smc: Forward wakeup to smc socket waitqueue after fallback
When we replace T
ghsa_unreviewed·2024-06-20
CVE-2022-48721 [MEDIUM] GHSA-cw8x-f629-7c3v: In the Linux kernel, the following vulnerability has been resolved:
net/smc: Forward wakeup to smc socket waitqueue after fallback
When we replace T
In the Linux kernel, the following vulnerability has been resolved:
net/smc: Forward wakeup to smc socket waitqueue after fallback
When we replace TCP with SMC and a fallback occurs, there may be
some socket waitqueue entries remaining in smc socket->wq, such
as eppoll_entries inserted by userspace applications.
After the fallback, data flows over TCP/IP and only clcsocket->wq
will be woken up. Applications can't be notified by the entries
which were inserted in smc socket->wq before fallback. So we need
a mechanism to wake up smc socket->wq at the same time if some
entries remaining in it.
The current workaround is to transfer the entries from smc socket->wq
to clcsock->wq during the fallback. But this may cause a crash
like this:
general protection fault, probably for non-canonical
Red Hat
kernel: net/smc: Forward wakeup to smc socket waitqueue after fallback
vendor_redhat·2024-06-20·CVSS 5.5
CVE-2022-48721 [MEDIUM] CWE-99 kernel: net/smc: Forward wakeup to smc socket waitqueue after fallback
kernel: net/smc: Forward wakeup to smc socket waitqueue after fallback
In the Linux kernel, the following vulnerability has been resolved:
net/smc: Forward wakeup to smc socket waitqueue after fallback
When we replace TCP with SMC and a fallback occurs, there may be
some socket waitqueue entries remaining in smc socket->wq, such
as eppoll_entries inserted by userspace applications.
After the fallback, data flows over TCP/IP and only clcsocket->wq
will be woken up. Applications can't be notified by the entries
which were inserted in smc socket->wq before fallback. So we need
a mechanism to wake up smc socket->wq at the same time if some
entries remaining in it.
The current workaround is to transfer the entries from smc socket->wq
to clcsock->wq during the fallback. But this may cause a cra
Debian
CVE-2022-48721: linux - In the Linux kernel, the following vulnerability has been resolved: net/smc: Fo...
vendor_debian·2022·CVSS 5.5
CVE-2022-48721 [MEDIUM] CVE-2022-48721: linux - In the Linux kernel, the following vulnerability has been resolved: net/smc: Fo...
In the Linux kernel, the following vulnerability has been resolved: net/smc: Forward wakeup to smc socket waitqueue after fallback When we replace TCP with SMC and a fallback occurs, there may be some socket waitqueue entries remaining in smc socket->wq, such as eppoll_entries inserted by userspace applications. After the fallback, data flows over TCP/IP and only clcsocket->wq will be woken up. Applications can't be notified by the entries which were inserted in smc socket->wq before fallback. So we need a mechanism to wake up smc socket->wq at the same time if some entries remaining in it. The current workaround is to transfer the entries from smc socket->wq to clcsock->wq during the fallback. But this may cause a crash like this: general protection fault, probably for non-canonical addre
No detection rules found.
No public exploits indexed.
No writeups or analysis indexed.
https://git.kernel.org/stable/c/0ef6049f664941bc0f75828b3a61877635048b27https://git.kernel.org/stable/c/341adeec9adad0874f29a0a1af35638207352a39https://git.kernel.org/stable/c/504078fbe9dd570d685361b57784a6050bc40aaahttps://git.kernel.org/stable/c/0ef6049f664941bc0f75828b3a61877635048b27https://git.kernel.org/stable/c/341adeec9adad0874f29a0a1af35638207352a39https://git.kernel.org/stable/c/504078fbe9dd570d685361b57784a6050bc40aaa
2024-06-20
Published