ghsa-q9gh-c678-j467
Vulnerability from github
In the Linux kernel, the following vulnerability has been resolved:
net: fix refcount bug in sk_psock_get (2)
Syzkaller reports refcount bug as follows: ------------[ cut here ]------------ refcount_t: saturated; leaking memory. WARNING: CPU: 1 PID: 3605 at lib/refcount.c:19 refcount_warn_saturate+0xf4/0x1e0 lib/refcount.c:19 Modules linked in: CPU: 1 PID: 3605 Comm: syz-executor208 Not tainted 5.18.0-syzkaller-03023-g7e062cda7d90 #0 __refcount_add_not_zero include/linux/refcount.h:163 [inline] __refcount_inc_not_zero include/linux/refcount.h:227 [inline] refcount_inc_not_zero include/linux/refcount.h:245 [inline] sk_psock_get+0x3bc/0x410 include/linux/skmsg.h:439 tls_data_ready+0x6d/0x1b0 net/tls/tls_sw.c:2091 tcp_data_ready+0x106/0x520 net/ipv4/tcp_input.c:4983 tcp_data_queue+0x25f2/0x4c90 net/ipv4/tcp_input.c:5057 tcp_rcv_state_process+0x1774/0x4e80 net/ipv4/tcp_input.c:6659 tcp_v4_do_rcv+0x339/0x980 net/ipv4/tcp_ipv4.c:1682 sk_backlog_rcv include/net/sock.h:1061 [inline] __release_sock+0x134/0x3b0 net/core/sock.c:2849 release_sock+0x54/0x1b0 net/core/sock.c:3404 inet_shutdown+0x1e0/0x430 net/ipv4/af_inet.c:909 __sys_shutdown_sock net/socket.c:2331 [inline] __sys_shutdown_sock net/socket.c:2325 [inline] __sys_shutdown+0xf1/0x1b0 net/socket.c:2343 __do_sys_shutdown net/socket.c:2351 [inline] __se_sys_shutdown net/socket.c:2349 [inline] __x64_sys_shutdown+0x50/0x70 net/socket.c:2349 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x46/0xb0
During SMC fallback process in connect syscall, kernel will replaces TCP with SMC. In order to forward wakeup smc socket waitqueue after fallback, kernel will sets clcsk->sk_user_data to origin smc socket in smc_fback_replace_callbacks().
Later, in shutdown syscall, kernel will calls sk_psock_get(), which treats the clcsk->sk_user_data as psock type, triggering the refcnt warning.
So, the root cause is that smc and psock, both will use sk_user_data field. So they will mismatch this field easily.
This patch solves it by using another bit(defined as SK_USER_DATA_PSOCK) in PTRMASK, to mark whether sk_user_data points to a psock object or not. This patch depends on a PTRMASK introduced in commit f1ff5ce2cd5e ("net, sk_msg: Clear sk_user_data pointer on clone if tagged").
For there will possibly be more flags in the sk_user_data field, this patch also refactor sk_user_data flags code to be more generic to improve its maintainability.
{
"affected": [],
"aliases": [
"CVE-2022-49979"
],
"database_specific": {
"cwe_ids": [],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-06-18T11:15:25Z",
"severity": null
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: fix refcount bug in sk_psock_get (2)\n\nSyzkaller reports refcount bug as follows:\n------------[ cut here ]------------\nrefcount_t: saturated; leaking memory.\nWARNING: CPU: 1 PID: 3605 at lib/refcount.c:19 refcount_warn_saturate+0xf4/0x1e0 lib/refcount.c:19\nModules linked in:\nCPU: 1 PID: 3605 Comm: syz-executor208 Not tainted 5.18.0-syzkaller-03023-g7e062cda7d90 #0\n \u003cTASK\u003e\n __refcount_add_not_zero include/linux/refcount.h:163 [inline]\n __refcount_inc_not_zero include/linux/refcount.h:227 [inline]\n refcount_inc_not_zero include/linux/refcount.h:245 [inline]\n sk_psock_get+0x3bc/0x410 include/linux/skmsg.h:439\n tls_data_ready+0x6d/0x1b0 net/tls/tls_sw.c:2091\n tcp_data_ready+0x106/0x520 net/ipv4/tcp_input.c:4983\n tcp_data_queue+0x25f2/0x4c90 net/ipv4/tcp_input.c:5057\n tcp_rcv_state_process+0x1774/0x4e80 net/ipv4/tcp_input.c:6659\n tcp_v4_do_rcv+0x339/0x980 net/ipv4/tcp_ipv4.c:1682\n sk_backlog_rcv include/net/sock.h:1061 [inline]\n __release_sock+0x134/0x3b0 net/core/sock.c:2849\n release_sock+0x54/0x1b0 net/core/sock.c:3404\n inet_shutdown+0x1e0/0x430 net/ipv4/af_inet.c:909\n __sys_shutdown_sock net/socket.c:2331 [inline]\n __sys_shutdown_sock net/socket.c:2325 [inline]\n __sys_shutdown+0xf1/0x1b0 net/socket.c:2343\n __do_sys_shutdown net/socket.c:2351 [inline]\n __se_sys_shutdown net/socket.c:2349 [inline]\n __x64_sys_shutdown+0x50/0x70 net/socket.c:2349\n do_syscall_x64 arch/x86/entry/common.c:50 [inline]\n do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80\n entry_SYSCALL_64_after_hwframe+0x46/0xb0\n \u003c/TASK\u003e\n\nDuring SMC fallback process in connect syscall, kernel will\nreplaces TCP with SMC. In order to forward wakeup\nsmc socket waitqueue after fallback, kernel will sets\nclcsk-\u003esk_user_data to origin smc socket in\nsmc_fback_replace_callbacks().\n\nLater, in shutdown syscall, kernel will calls\nsk_psock_get(), which treats the clcsk-\u003esk_user_data\nas psock type, triggering the refcnt warning.\n\nSo, the root cause is that smc and psock, both will use\nsk_user_data field. So they will mismatch this field\neasily.\n\nThis patch solves it by using another bit(defined as\nSK_USER_DATA_PSOCK) in PTRMASK, to mark whether\nsk_user_data points to a psock object or not.\nThis patch depends on a PTRMASK introduced in commit f1ff5ce2cd5e\n(\"net, sk_msg: Clear sk_user_data pointer on clone if tagged\").\n\nFor there will possibly be more flags in the sk_user_data field,\nthis patch also refactor sk_user_data flags code to be more generic\nto improve its maintainability.",
"id": "GHSA-q9gh-c678-j467",
"modified": "2025-06-18T12:30:39Z",
"published": "2025-06-18T12:30:39Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49979"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/2a0133723f9ebeb751cfce19f74ec07e108bef1f"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/61cc798591a36ca27eb7d8d6c09bf20e50a59968"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/86026be8535c16fcc5e4f960286faf04d7f77815"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a5d1cb908131e939bd8b63b8e5e23365bbc2edaf"
}
],
"schema_version": "1.4.0",
"severity": []
}
Sightings
| Author | Source | Type | Date |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or seen somewhere by the user.
- Confirmed: The vulnerability is confirmed from an analyst perspective.
- Exploited: This vulnerability was exploited and seen by the user reporting the sighting.
- Patched: This vulnerability was successfully patched by the user reporting the sighting.
- Not exploited: This vulnerability was not exploited or seen by the user reporting the sighting.
- Not confirmed: The user expresses doubt about the veracity of the vulnerability.
- Not patched: This vulnerability was not successfully patched by the user reporting the sighting.