CVE-2022-48721

net/smc: Forward wakeup to smc socket waitqueue after fallback

MEDIUM
5.5
CVSS Score
Published: June 20, 2024 at 11:13 AM UTC
Updated: August 5, 2026 at 09:24 AM UTC
1 product affected across 1 vendorLinux Kernel

Using Linux by Linux?

Get instant alerts when new vulnerabilities affect Linux - before attackers find them.

Real-time alertsTrack your software stackFree plan available
Severity
MEDIUM5.5
Exploit prediction
EPSS 0.2%
SSVC
No known exploit

Description

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: <IRQ> __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 </IRQ> <TASK> 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) to make the entries operation exclusive, but it doesn't work. The operations to the entries, such as removing from the waitqueue (now is clcsock->wq after fallback), may cause a crash when clcsock waitqueue is being iterated over at the moment. This patch tries to fix this by no longer transferring wait queue entries privately, but introducing own implementations of clcsock's callback functions in fallback situation. The callback functions will forward the wakeup to smc socket->wq if clcsock->wq is actually woken up and smc socket->wq has remaining entries.

Affected

Our own answer: ranges merged, affected separated from platform-only, with confidence and review flags.

v ≥ 5.10.84v ≥ 5.4.1645.10.84 ≤ v < 5.115.15.7 ≤ v < 5.15.225.16 ≤ v < 5.16.85.16 ≤ v < 5.175.16.1 ≤ v < 5.16.85.4.164 ≤ v < 5.52153bd1e3d3dbf6a3403572084ef6ed31c53c5f05.10.845.15.75.165.16 rc25.16 rc35.16 rc45.16 rc55.16 rc65.16 rc75.16 rc85.17 rc15.17 rc25.4.164d6e981ec9491be5ec46d838b1151e7edefe607f5fb92e025baa73e99250b79ab64f4e088d2888993ff6eeb627898c179aac421af5d6515d3f50b84df
Vendor states this is fixed in 0ef6049f664941bc0f75828b3a61877635048b27 (fixed)
Vendor states this is fixed in 341adeec9adad0874f29a0a1af35638207352a39 (fixed)
Vendor states this is fixed in 504078fbe9dd570d685361b57784a6050bc40aaa (fixed)
Affected range stops below 5.11, so it looks safe — our inference, not a vendor statement
Vendor states this is fixed in 5.15.22 (unaffected)
Vendor states this is fixed in 5.16 (unaffected)
Vendor states this is fixed in 5.16.8 (unaffected)
Vendor states this is fixed in 5.17 (unaffected)
Affected range stops below 5.5, so it looks safe — our inference, not a vendor statement

References (3)

Patch
Source: 416baaa9-dc9f-4396-8d5f-8c081fb06d67
https://git.kernel.org/stable/c/0ef6049f664941bc0f75828b3a61877635048b27
Patch
Source: 416baaa9-dc9f-4396-8d5f-8c081fb06d67
https://git.kernel.org/stable/c/341adeec9adad0874f29a0a1af35638207352a39
Patch
Source: 416baaa9-dc9f-4396-8d5f-8c081fb06d67
https://git.kernel.org/stable/c/504078fbe9dd570d685361b57784a6050bc40aaa

SSVC — Action Prioritization

SSVCNo known exploitNot automatablePartial impact

SSVC signals action urgency (what to patch first), separate from CVSS which measures severity.

CVSS

Attack Vector
LOCAL
Complexity
LOW
Privileges
LOW
User Interaction
NONE
Scope
UNCHANGED
Confidentiality
NONE
Integrity
NONE
Availability
HIGH
Vector?

Quick Info

StatusMODIFIED
CWE
NVD-CWE-noinfo

Get alerted

Stop reading CVE feeds looking for your own stack

Track the products you run and VulnTracker tells you when a new CVE affects them — with what is known about fixing it, and nothing about the rest.

Free plan, no card