linux — security advisory
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
- Products
- linux
- Affected versions
- Not specified
- Fixed versions
- 5.16.10-1
- CVEs
- CVE-2022-48721
- Confirmed fixed CVEs
- Not specified
- Updated in this feed
- 30 Oct 2026, 14:52 UTC · Revision 1
Source evidence
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
osv:DEBIAN-CVE-2022-48721
linux
Fixed versions: 5.16.10-1
linux
Fixed versions: 5.16.10-1
linux
Fixed versions: 5.16.10-1
Complete source record
{
"id": "2244317c02ed107a70b48e0026a513cd3a8d541dfb8f146880f99955d1900f94",
"url": "https://osv.dev/vulnerability/DEBIAN-CVE-2022-48721",
"method": "structured",
"payload": {
"kind": "advisory",
"title": "DEBIAN-CVE-2022-48721",
"summary": "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 ",
"evidence": "osv:DEBIAN-CVE-2022-48721",
"products": [
{
"name": {
"value": "linux",
"evidence": "/affected/0/package/name"
},
"prerequisites": [],
"fixed_versions": [
{
"value": "5.16.10-1",
"evidence": "/affected/0/ranges"
}
],
"affected_versions": []
},
{
"name": {
"value": "linux",
"evidence": "/affected/1/package/name"
},
"prerequisites": [],
"fixed_versions": [
{
"value": "5.16.10-1",
"evidence": "/affected/1/ranges"
}
],
"affected_versions": []
},
{
"name": {
"value": "linux",
"evidence": "/affected/2/package/name"
},
"prerequisites": [],
"fixed_versions": [
{
"value": "5.16.10-1",
"evidence": "/affected/2/ranges"
}
],
"affected_versions": []
}
],
"severity": "medium",
"structured": {
"id": "DEBIAN-CVE-2022-48721",
"aliases": [
"DEBIAN-CVE-2022-48721"
],
"metrics": [
{
"type": "CVSS_V3",
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H"
}
],
"affected": [
{
"ranges": [
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "0"
},
{
"fixed": "5.16.10-1"
}
]
}
],
"package": {
"name": "linux",
"purl": "pkg:deb/debian/linux?arch=source&distro=bookworm",
"ecosystem": "Debian:12"
},
"database_specific": {
"source": "https://storage.googleapis.com/debian-osv/debian-cve-osv/DEBIAN-CVE-2022-48721.json"
},
"ecosystem_specific": {
"urgency": "not yet assigned"
}
},
{
"ranges": [
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "0"
},
{
"fixed": "5.16.10-1"
}
]
}
],
"package": {
"name": "linux",
"purl": "pkg:deb/debian/linux?arch=source&distro=trixie",
"ecosystem": "Debian:13"
},
"database_specific": {
"source": "https://storage.googleapis.com/debian-osv/debian-cve-osv/DEBIAN-CVE-2022-48721.json"
},
"ecosystem_specific": {
"urgency": "not yet assigned"
}
},
{
"ranges": [
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "0"
},
{
"fixed": "5.16.10-1"
}
]
}
],
"package": {
"name": "linux",
"purl": "pkg:deb/debian/linux?arch=source&distro=forky",
"ecosystem": "Debian:14"
},
"database_specific": {
"source": "https://storage.googleapis.com/debian-osv/debian-cve-osv/DEBIAN-CVE-2022-48721.json"
},
"ecosystem_specific": {
"urgency": "not yet assigned"
}
}
],
"modified": "2026-10-15T08:02:33.503580239Z",
"provider": "osv",
"upstream": [
"CVE-2022-48721"
],
"references": [
"https://security-tracker.debian.org/tracker/CVE-2022-48721"
]
},
"related_cves": [
{
"value": "CVE-2022-48721",
"evidence": "/upstream"
}
],
"security_relevant": true,
"severity_evidence": "/severity/0/score"
},
"source_id": "core-osv",
"document_id": 323605,
"published_at": "2024-06-20T11:15:55.62+00:00"
}