{ "schema_version": "1.6.1", "id": "RPI-CVE-2026-68117", "modified": "2026-10-09T11:39:44Z", "upstream": [ "CVE-2026-68117" ], "published": "2026-08-10T12:08:00Z", "summary": "tipc: clear sock->sk on the failed-insert path in tipc_sk_create()", "details": "In the Linux kernel, the following vulnerability has been resolved:\n\ntipc: clear sock->sk on the failed-insert path in tipc_sk_create()\n\nWhen tipc_sk_create() fails to insert the new socket (tipc_sk_insert()\nreturns non-zero), its error path frees the sk with sk_free() but leaves\nsock->sk pointing at the freed object:\n\n\tif (tipc_sk_insert(tsk)) {\n\t\tsk_free(sk);\n\t\tpr_warn(\"Socket create failed; port number exhausted\\n\");\n\t\treturn -EINVAL;\n\t}\n\nThis is harmless for plain socket(): the syscall layer clears sock->ops\nbefore releasing, so tipc_release() is never called. It is not harmless\non the accept() path. tipc_accept() creates the pre-allocated child\nsocket with tipc_sk_create(net, new_sock, 0, kern); on failure it leaves\nnew_sock->sk dangling and new_sock->ops non-NULL, and do_accept() then\nfput()s the new file, so __sock_release() -> tipc_release() runs\nlock_sock(new_sock->sk) on the freed sk -- a use-after-free write of the\nsk_lock spinlock.\n\ntipc_release() already guards this exact \"failed accept() releases a\npre-allocated child\" case with \"if (sk == NULL) return 0;\", but the\nguard is bypassed because tipc_sk_create() left sock->sk non-NULL\n(dangling) rather than NULL.\n\nClear sock->sk on the failed-insert path so the existing tipc_release()\nNULL check fires and the use-after-free is avoided.\n\nThe tipc_sk_insert() failure is reached when the per-netns socket\nrhashtable hits its max_size (tsk_rht_params.max_size = 1048576, ~2M\nelements) -- i.e. once a netns holds ~2M TIPC sockets every insert\nreturns -E2BIG.\n\n BUG: KASAN: slab-use-after-free in lock_sock_nested (net/core/sock.c:3839)\n Write of size 8 at addr ffff8880047cdc38 by task init/1\n lock_sock_nested (net/core/sock.c:3839)\n tipc_release (net/tipc/socket.c:638)\n __sock_release (net/socket.c:710)\n sock_close (net/socket.c:1501)\n __fput (fs/file_table.c:512)\n Allocated by task 1:\n sk_alloc (net/core/sock.c:2308)\n tipc_sk_create (net/tipc/socket.c:487)\n tipc_accept (net/tipc/socket.c:2744)\n do_accept (net/socket.c:2034)\n Freed by task 1:\n __sk_destruct (net/core/sock.c:2391)\n tipc_sk_create (net/tipc/socket.c:504)\n tipc_accept (net/tipc/socket.c:2744)\n do_accept (net/socket.c:2034)", "severity": [ { "type": "CVSS_V3", "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H" } ], "affected": [ { "package": { "ecosystem": "Raspberry Pi OS:12", "name": "linux" }, "versions": [ "1:6.1.47-1+rpt4" ], "ecosystem_specific": { "binaries": [ { "binary_name": "linux-image-6.1.0-rpi3-rpi-2712", "binary_version": "1:6.1.47-1+rpt4" }, { "binary_name": "linux-image-6.1.0-rpi3-rpi-v6", "binary_version": "1:6.1.47-1+rpt4" }, { "binary_name": "linux-image-6.1.0-rpi3-rpi-v7", "binary_version": "1:6.1.47-1+rpt4" }, { "binary_name": "linux-image-6.1.0-rpi3-rpi-v7l", "binary_version": "1:6.1.47-1+rpt4" }, { "binary_name": "linux-image-6.1.0-rpi3-rpi-v8", "binary_version": "1:6.1.47-1+rpt4" } ] }, "database_specific": { "per_version": { "1:6.1.47-1+rpt4": { "linux_commit": "655fc658a15ae7a6f37103754adb39ba52a9a14e", "upstream_version": "6.1.47", "assessment": "commit ancestry (strak rule)", "upstream_fixed": "6.1.183", "compiled_filter": false } } } } ], "references": [ { "type": "ADVISORY", "url": "https://www.cve.org/CVERecord?id=CVE-2026-68117" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/efebc23e9b29e3e5a9e2127dd066929f7f0d315e" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/8d6f26d48e61ef34f1921289401dbf36b10816af" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/82f59aa27f33bd014a7d8739371ab5712d15e33b" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/b07d87b31631edb6529e6cdcca790a7489d1250d" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/dd29891ed840f6b8d020b759d0dc4a00b1d6e4ea" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/5f5a41a48dbf9eda57b67ce23e548602cf7195a6" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/f9596b1566616a8be0592dbceccb6344a7c6f6bb" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/ba0533fc163f905fe817cfabdf8ed4058da44800" } ], "database_specific": { "source": "https://git.kernel.org/pub/scm/linux/security/vulns.git", "upstream_modified": "2026-08-19T16:47:12Z", "severity": { "source": "kernel CNA", "cvss_v3_score": 9.8, "cvss_v3_severity": "Critical", "scenario": "AV:N - The bug is hit in tipc_accept() when a listening SOCK_STREAM/SOCK_SEQPACKET socket accepts an incoming TIPC connection; peers reach this path over default UDP/Ethernet bearers (e.g. UDP/6118) without local syscall access.\nAC:L - An attacker can deterministically fill the per-netns TIPC socket rhashtable (~2M entries) by opening many sockets or connections, then trigger the failed-insert accept() cleanup path that performs lock_sock() on the freed sk.\nPR:N - No elevated Linux capabilities are required to create AF_TIPC stream/seqpacket sockets or send unauthenticated TIPC SYN traffic to a listening cluster service; only LSM policy may restrict access.\nUI:N - Exploitation needs no end-user action beyond a server\u2019s normal accept() loop processing inbound TIPC connection requests queued by the network stack.\nS:U - The use-after-free corrupts kernel heap memory within the same kernel security domain; impact is kernel privilege escalation or crash, not a VM/hypervisor or IOMMU boundary crossing.\nC:H - tipc_release() calls lock_sock() on a freed struct sock, a slab use-after-free that can be groomed for arbitrary kernel memory disclosure via controlled reuse of the freed socket object.\nI:H - The UAF performs an 8-byte write to sk_lock on freed memory during socket teardown, enabling heap corruption and potential arbitrary kernel write or code execution primitives.\nA:H - KASAN reports slab-use-after-free in lock_sock_nested during tipc_release on the failed accept() path, causing kernel oops/panic and denial of service even without full exploitation." } } }