af_unix: Call kfree_skb() for dead unix_(sk)->oob_skb in GC.
In the Linux kernel, the following vulnerability has been resolved: af_unix: Call kfree_skb() for dead unix_(sk)->oob_skb in GC. syzbot reported a warning [0] in __unix_gc() with a repro, which creates a socketpair and sends one socket's fd to itself using the peer. socketpair(AF_UNIX, SOCK_STREAM, 0, [3, 4]) = 0 sendmsg(4, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="\360", iov_len=1}], msg_iovlen=1, msg_control=[{cmsg_len=20, cmsg_level=SOL_SOCKET, cmsg_type=SCM_RIGHTS, cmsg_data=[3]}], msg_controllen=24, msg_flags=0}, MSG_OOB|MSG_PROBE|MSG_DONTWAIT|MSG_ZEROCOPY) = 1 This forms a self-cyclic reference that GC should finally untangle but does not due to lack of MSG_OOB handling, resulting in memory leak. Recently, commit 11498715f266 ("af_unix: Remove io_uring code for GC.") removed io_uring's dead code in GC and revealed the problem. The code was executed at the final stage of GC and unconditionally moved all GC candidates from gc_candidates to gc_inflight_list. That papered over the reported problem by always making the following WARN_ON_ONCE(!list_empty(&gc_candidates)) false. The problem has been there since commit 2aab4b969002 ("af_unix: fix struct pid leaks in OOB support") added full scm support for MSG_OOB while fixing another bug. To fix this problem, we must call kfree_skb() for unix_sk(sk)->oob_skb if the socket still exists in gc_candidates after purging collected skb. Then, we need to set NULL to oob_skb before calling kfree_skb() because it calls last fpu
- Products
- Kernel
- Affected versions
- Not specified
- Fixed versions
- 5.15.149, 6.1.78, 6.6.17, 6.7.5
- CVEs
- CVE-2024-26676
- Confirmed fixed CVEs
- Not specified
- Updated in this feed
- 6 Nov 2026, 03:35 UTC · Revision 1
Source evidence
af_unix: Call kfree_skb() for dead unix_(sk)->oob_skb in GC.
core-osv · Original sourcePublished 2 Apr 2024, 07:01 UTC
In the Linux kernel, the following vulnerability has been resolved: af_unix: Call kfree_skb() for dead unix_(sk)->oob_skb in GC. syzbot reported a warning [0] in __unix_gc() with a repro, which creates a socketpair and sends one socket's fd to itself using the peer. socketpair(AF_UNIX, SOCK_STREAM, 0, [3, 4]) = 0 sendmsg(4, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="\360", iov_len=1}], msg_iovlen=1, msg_control=[{cmsg_len=20, cmsg_level=SOL_SOCKET, cmsg_type=SCM_RIGHTS, cmsg_data=[3]}], msg_controllen=24, msg_flags=0}, MSG_OOB|MSG_PROBE|MSG_DONTWAIT|MSG_ZEROCOPY) = 1 This forms a self-cyclic reference that GC should finally untangle but does not due to lack of MSG_OOB handling, resulting in memory leak. Recently, commit 11498715f266 ("af_unix: Remove io_uring code for GC.") removed io_uring's dead code in GC and revealed the problem. The code was executed at the final stage of GC and unconditionally moved all GC candidates from gc_candidates to gc_inflight_list. That papered over the reported problem by always making the following WARN_ON_ONCE(!list_empty(&gc_candidates)) false. The problem has been there since commit 2aab4b969002 ("af_unix: fix struct pid leaks in OOB support") added full scm support for MSG_OOB while fixing another bug. To fix this problem, we must call kfree_skb() for unix_sk(sk)->oob_skb if the socket still exists in gc_candidates after purging collected skb. Then, we need to set NULL to oob_skb before calling kfree_skb() because it calls last fpu
osv:CVE-2024-26676
Kernel
Fixed versions: 5.15.149, 6.1.78, 6.6.17, 6.7.5
Complete source record
{
"id": "3f126166a8a429763a3d04aaff632bd16c7be4b501bfbbf7459ece2bd9484883",
"url": "https://osv.dev/vulnerability/CVE-2024-26676",
"method": "structured",
"payload": {
"kind": "advisory",
"title": "af_unix: Call kfree_skb() for dead unix_(sk)->oob_skb in GC.",
"summary": "In the Linux kernel, the following vulnerability has been resolved: af_unix: Call kfree_skb() for dead unix_(sk)->oob_skb in GC. syzbot reported a warning [0] in __unix_gc() with a repro, which creates a socketpair and sends one socket's fd to itself using the peer. socketpair(AF_UNIX, SOCK_STREAM, 0, [3, 4]) = 0 sendmsg(4, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base=\"\\360\", iov_len=1}], msg_iovlen=1, msg_control=[{cmsg_len=20, cmsg_level=SOL_SOCKET, cmsg_type=SCM_RIGHTS, cmsg_data=[3]}], msg_controllen=24, msg_flags=0}, MSG_OOB|MSG_PROBE|MSG_DONTWAIT|MSG_ZEROCOPY) = 1 This forms a self-cyclic reference that GC should finally untangle but does not due to lack of MSG_OOB handling, resulting in memory leak. Recently, commit 11498715f266 (\"af_unix: Remove io_uring code for GC.\") removed io_uring's dead code in GC and revealed the problem. The code was executed at the final stage of GC and unconditionally moved all GC candidates from gc_candidates to gc_inflight_list. That papered over the reported problem by always making the following WARN_ON_ONCE(!list_empty(&gc_candidates)) false. The problem has been there since commit 2aab4b969002 (\"af_unix: fix struct pid leaks in OOB support\") added full scm support for MSG_OOB while fixing another bug. To fix this problem, we must call kfree_skb() for unix_sk(sk)->oob_skb if the socket still exists in gc_candidates after purging collected skb. Then, we need to set NULL to oob_skb before calling kfree_skb() because it calls last fpu",
"evidence": "osv:CVE-2024-26676",
"products": [
{
"name": {
"value": "Kernel",
"evidence": "/affected/1/package/name"
},
"prerequisites": [],
"fixed_versions": [
{
"value": "5.15.149",
"evidence": "/affected/1/ranges"
},
{
"value": "6.1.78",
"evidence": "/affected/1/ranges"
},
{
"value": "6.6.17",
"evidence": "/affected/1/ranges"
},
{
"value": "6.7.5",
"evidence": "/affected/1/ranges"
}
],
"affected_versions": []
}
],
"severity": "medium",
"structured": {
"id": "CVE-2024-26676",
"aliases": [
"CVE-2024-26676"
],
"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": [
{
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"type": "GIT",
"events": [
{
"introduced": "f3969427fb06a2c3cd6efd7faab63505cfa76e76"
},
{
"fixed": "4fe505c63aa3273135a57597fda761e9aecc7668"
}
]
},
{
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"type": "GIT",
"events": [
{
"introduced": "ac1968ac399205fda9ee3b18f7de7416cb3a5d0d"
},
{
"fixed": "e0e09186d8821ad59806115d347ea32efa43ca4b"
}
]
},
{
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"type": "GIT",
"events": [
{
"introduced": "2aab4b96900272885bc157f8b236abf1cdc02e08"
},
{
"fixed": "b74aa9ce13d02b7fd37c5325b99854f91b9b4276"
},
{
"fixed": "82ae47c5c3a6b27fdc0f9e83c1499cb439c56140"
},
{
"fixed": "1279f9d9dec2d7462823a18c29ad61359e0a007d"
}
]
},
{
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"type": "GIT",
"events": [
{
"introduced": "5.15.103"
},
{
"fixed": "5.15.149"
}
]
},
{
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"type": "GIT",
"events": [
{
"introduced": "6.1.20"
},
{
"fixed": "6.1.78"
}
]
},
{
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"type": "GIT",
"events": [
{
"introduced": "6.2.7"
},
{
"fixed": "6.3"
}
]
},
{
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"type": "GIT",
"events": [
{
"introduced": "a59d6306263c38e5c0592ea4451ca26a0778c947"
}
]
}
],
"versions": [
"v5.15.148",
"v5.15.147",
"v5.15.146",
"v5.15.145",
"v5.15.144",
"v5.15.143",
"v5.15.142",
"v5.15.141",
"v5.15.140",
"v5.15.139",
"v5.15.138",
"v5.15.137",
"v5.15.136",
"v5.15.135",
"v5.15.134",
"v5.15.133",
"v5.15.132",
"v5.15.131",
"v5.15.130",
"v5.15.129",
"v5.15.128",
"v5.15.127",
"v5.15.126",
"v5.15.125",
"v5.15.124",
"v5.15.123",
"v5.15.122",
"v5.15.121",
"v5.15.120",
"v5.15.119",
"v5.15.118",
"v5.15.117",
"v5.15.116",
"v5.15.115",
"v5.15.114",
"v5.15.113",
"v5.15.112",
"v5.15.111",
"v5.15.110",
"v5.15.109",
"v5.15.108",
"v5.15.107",
"v5.15.106",
"v5.15.105",
"v5.15.104",
"v5.15.103",
"v6.1.77",
"v6.1.76",
"v6.1.75",
"v6.1.74",
"v6.1.73",
"v6.1.72",
"v6.1.71",
"v6.1.70",
"v6.1.69",
"v6.1.68",
"v6.1.67",
"v6.1.66",
"v6.1.65",
"v6.1.64",
"v6.1.63",
"v6.1.62",
"v6.1.61",
"v6.1.60",
"v6.1.59",
"v6.1.58",
"v6.1.57",
"v6.1.56",
"v6.1.55",
"v6.1.54",
"v6.1.53",
"v6.1.52",
"v6.1.51",
"v6.1.50",
"v6.1.49",
"v6.1.48",
"v6.1.47",
"v6.1.46",
"v6.1.45",
"v6.1.44",
"v6.1.43",
"v6.1.42",
"v6.1.41",
"v6.1.40",
"v6.1.39",
"v6.1.38",
"v6.1.37",
"v6.1.36",
"v6.1.35",
"v6.1.34",
"v6.1.33",
"v6.1.32",
"v6.1.31",
"v6.1.30",
"v6.1.29",
"v6.1.28",
"v6.1.27",
"v6.1.26",
"v6.1.25",
"v6.1.24",
"v6.1.23",
"v6.1.22",
"v6.1.21",
"v6.1.20",
"v6.2.16",
"v6.2.15",
"v6.2.14",
"v6.2.13",
"v6.2.12",
"v6.2.11",
"v6.2.10",
"v6.2.9",
"v6.2.8",
"v6.2.7"
],
"database_specific": {
"source": "https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2024-26676.json"
}
},
{
"ranges": [
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "0"
},
{
"fixed": "5.15.149"
}
]
},
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "5.16.0"
},
{
"fixed": "6.1.78"
}
]
},
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "6.2.0"
},
{
"fixed": "6.6.17"
}
]
},
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "6.3.0"
},
{
"fixed": "6.7.5"
}
]
}
],
"package": {
"name": "Kernel",
"ecosystem": "Linux"
},
"database_specific": {
"source": "https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2024-26676.json"
}
}
],
"modified": "2026-10-28T02:30:46.677783335Z",
"provider": "osv",
"references": [
"https://git.kernel.org/stable/c/1279f9d9dec2d7462823a18c29ad61359e0a007d",
"https://git.kernel.org/stable/c/4fe505c63aa3273135a57597fda761e9aecc7668",
"https://git.kernel.org/stable/c/82ae47c5c3a6b27fdc0f9e83c1499cb439c56140",
"https://git.kernel.org/stable/c/b74aa9ce13d02b7fd37c5325b99854f91b9b4276",
"https://git.kernel.org/stable/c/e0e09186d8821ad59806115d347ea32efa43ca4b",
"https://github.com/CVEProject/cvelistV5/tree/main/cves/2024/26xxx/CVE-2024-26676.json",
"https://nvd.nist.gov/vuln/detail/CVE-2024-26676",
"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git"
],
"provider_metadata": {
"cna_assigner": "Linux",
"osv_generated_from": "https://github.com/CVEProject/cvelistV5/tree/main/cves/2024/26xxx/CVE-2024-26676.json"
}
},
"related_cves": [
{
"value": "CVE-2024-26676",
"evidence": "/id"
}
],
"security_relevant": true,
"severity_evidence": "/severity/0/score"
},
"source_id": "core-osv",
"document_id": 514505,
"published_at": "2024-04-02T07:01:40.758+00:00"
}