[CVE-2026-68117][MODERATE 7.0] tipc: clear sock->sk on the failed-insert path in tipc_sk_create()

[AL-KERNEL <alkernel@kernelcve.org>]

CVE: CVE-2026-68117
Priority: MODERATE 7.0
AL-KERNEL base severity: MODERATE
KPANIC flag: YES
Patch: tipc: clear sock->sk on the failed-insert path in tipc_sk_create()
Commit: b07d87b31631edb6529e6cdcca790a7489d1250d
Upstream patch: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=b07d87b31631edb6529e6cdcca790a7489d1250d
Original CVE announcement: https://lore.kernel.org/linux-cve-announce/?q=CVE-2026-68117
Analysis date: Mon, 10 Aug 2026 14:13:33 -0400
ActionableScore: 6
ActionableScore lower bound: 4
Actionable bucket: Strong Important candidate / Actionable Moderate at minimum
Manual review required: YES

Summary:
A failed TIPC socket insert can leave `sock->sk` pointing to freed memory in the `accept()` path, causing `tipc_release()` to write through a dangling socket pointer and potentially crash the kernel or require further review for UAF exploitability.

======================================================================
ABOUT THIS REPORT
======================================================================

The original Linux kernel CVE announcement for CVE-2026-68117 is available here:
https://lore.kernel.org/linux-cve-announce/?q=CVE-2026-68117

The original announcement does not normally provide a security severity
estimate, CVSS assessment, or enough information to determine whether the
reported kernel bug represents a practically relevant security issue.

This report was generated by AL-KERNEL, an AI-assisted Linux kernel
vulnerability analysis system developed by Alexander Larkin. It combines
an autonomous classifier with LLM-assisted technical analysis and a
separate ActionableScore mechanism.

The purpose of this report is to prioritize Linux kernel CVEs before
manual review, identify cases that require prompt investigation, and
support automatic closure of issues that are unlikely to have meaningful
security impact.

Published priority for this report: MODERATE 7.0
Manual review required: YES

A detailed explanation of the methodology and priority rules is included
at the end of this message.

======================================================================
AL-KERNEL CLASSIFICATION RESULT
======================================================================

CVE-2026-68117	MODERATE	CHECK WITH IMPACT FROM ORIG NN IMPORTANT	Maybe valid. Check manually. Hints by AL-KERNEL: The best (paranoid) CVSS is 'AV:A/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H';*CWE-416;CWE-825;*CWE-672;Other CVSS 'AV:L/AC:H/PR:L/UI:N/S:U/C:L/I:L/A:H';BEST CVSS score: '7.5';DESCR 'A use after free write exists in the TIPC accept path because tipc_sk_create can free sk after tipc_sk_insert fails while leaving sock sk pointing to the freed object. During a failed accept, the pre allocated child socket can later be released with new_sock sk still dangling, causing tipc_release to call lock_sock on freed memory and write to the freed sk_lock state. For the CVSS the PR:N is used in the paranoid score because a remote TIPC peer may be able to trigger the accept path if it can reach a TIPC listener, although practical triggering requires the per netns TIPC socket table to be exhausted. The issue is not Internet wide in typical deployments and is more realistic on local or adjacent TIPC networks. Impact is at least denial of service via kernel crash and in worst case may allow confidentiality and integrity impact because the primitive is a use after free write.';YES REQUIRES MANUAL CHECK; ,and ActionableScore result is Strong Important candidate / Actionable Moderate at minimum (with actual score 5)	YES	WRITE OOB TIPC LEAK ERRORPATH UAF IMPROVEONLY  KPANIC DECREASED_TO_MODERATE70_BASED_ON_ACTIONABLESCORELOWERTHAN7	NO	NO	checked

======================================================================
ACTIONABLESCORE ANALYSIS
======================================================================

ActionableScore=6
ActionableScoreLower=4

## 1. ActionableScore

* Conservative score: 4
* Paranoid score: 6
* Final recommended bucket: **Strong Important candidate / Actionable Moderate at minimum**::

## 2. Signal breakdown

Conservative scoring:

* Local unprivileged trigger: +1. A local user may create TIPC sockets if AF_TIPC is available in the target configuration.
* Generic memory corruption: +2. The patch and KASAN trace show a real slab use-after-free.
* Real lifetime corruption: +1. `sock->sk` remains as a dangling pointer after `sk_free(sk)`.
* Reliable kernel crash / strong DoS: +1. The trace shows `lock_sock_nested()` writing through a freed `sk`.
* Weak LPE concern: +1. This is a write-after-free sink, but there is no demonstrated attacker-controlled reclaim or object replacement.
* Corruption primitive highly constrained: -1. The write is to the socket lock state and the payload is not clearly attacker-controlled.
* Hard special condition: -1. Triggering requires the per-netns TIPC socket rhashtable to hit its max size.
* Rare / difficult-to-reach subsystem: -1. TIPC is not a broad default Internet-facing protocol in typical deployments.

Paranoid scoring:

* Adjacent or network-triggerable path: +2. A reachable TIPC listener may allow a remote TIPC peer to drive the `accept()` path.
* Generic memory corruption: +2. The bug is a concrete UAF write, not just a NULL dereference or warning.
* Real lifetime corruption: +1. The freed `sk` remains reachable through `new_sock->sk`.
* Reliable kernel crash / strong DoS: +1. The failure path reaches a KASAN-confirmed UAF write.
* Weak LPE concern: +1. UAF write makes privilege escalation worth review, although no controlled reclaim primitive is shown.
* Hard special condition: -1. The socket table exhaustion requirement is substantial.
* Rare / difficult-to-reach subsystem: -1. TIPC exposure is usually limited to specific clustered or local/adjacent deployments.

Paranoid total: 6.

## 3. Reachability analysis

A local user can potentially trigger this if TIPC is enabled and the user can create enough TIPC sockets in the relevant network namespace to exhaust the per-netns socket rhashtable. The `accept()` path is important because plain `socket()` failure is described as harmless, while failed preallocated child socket creation leaves `new_sock->sk` dangling and later reaches `tipc_release()`.

A network-adjacent interpretation is plausible if a TIPC listener is reachable and a peer can cause server-side accepts while the namespace socket table is exhausted. This is not a typical public Internet exposure. It is more realistic in local, clustered, container, or adjacent TIPC network environments.

Namespaces matter because the exhaustion condition is per-netns. If untrusted users can create sockets inside a delegated netns where TIPC is available, the practical privilege level may be closer to PR:L than PR:H.

Call-site confidence: high. The commit message gives the exact call chain from `tipc_accept()` to `__sock_release()` and includes the KASAN UAF trace.

## 4. Severity interpretation

This is more than an ordinary Moderate correctness issue because the primitive is a real use-after-free write in a kernel networking socket lifetime path. Realistic exploitation is constrained by the need to exhaust the TIPC socket table and by lack of demonstrated reclaim or controlled overwrite.

The conservative view is borderline manual-review Moderate. The paranoid view is Actionable Moderate and possible Important candidate because the bug is a UAF write in an accept path that may be reachable from an adjacent TIPC peer.

## 5. One-sentence report phrase

A failed TIPC socket insert can leave `sock->sk` pointing to freed memory in the `accept()` path, causing `tipc_release()` to write through a dangling socket pointer and potentially crash the kernel or require further review for UAF exploitability.

## 6. Manual review recommendation

MANUAL CHECK REQUIRED

Reason: the patch shows a concrete UAF write primitive with a clear accept-path call chain. Even though exploitation is constrained by TIPC availability and socket table exhaustion, kernel lifetime corruption in a networking path should not be auto-closed.

======================================================================
UPSTREAM PATCH SUMMARY
======================================================================

Patch: tipc: clear sock->sk on the failed-insert path in tipc_sk_create()
Commit: b07d87b31631edb6529e6cdcca790a7489d1250d
Upstream URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=b07d87b31631edb6529e6cdcca790a7489d1250d

Commit description:

When tipc_sk_create() fails to insert the new socket (tipc_sk_insert()
returns non-zero), its error path frees the sk with sk_free() but leaves
sock->sk pointing at the freed object:

	if (tipc_sk_insert(tsk)) {
		sk_free(sk);
		pr_warn("Socket create failed; port number exhausted\n");
		return -EINVAL;
	}

This is harmless for plain socket(): the syscall layer clears sock->ops
before releasing, so tipc_release() is never called. It is not harmless
on the accept() path. tipc_accept() creates the pre-allocated child
socket with tipc_sk_create(net, new_sock, 0, kern); on failure it leaves
new_sock->sk dangling and new_sock->ops non-NULL, and do_accept() then
fput()s the new file, so __sock_release() -> tipc_release() runs
lock_sock(new_sock->sk) on the freed sk -- a use-after-free write of the
sk_lock spinlock.

tipc_release() already guards this exact "failed accept() releases a
pre-allocated child" case with "if (sk == NULL) return 0;", but the
guard is bypassed because tipc_sk_create() left sock->sk non-NULL
(dangling) rather than NULL.

Clear sock->sk on the failed-insert path so the existing tipc_release()
NULL check fires and the use-after-free is avoided.

The tipc_sk_insert() failure is reached when the per-netns socket
rhashtable hits its max_size (tsk_rht_params.max_size = 1048576, ~2M
elements) -- i.e. once a netns holds ~2M TIPC sockets every insert
returns -E2BIG.

  BUG: KASAN: slab-use-after-free in lock_sock_nested (net/core/sock.c:3839)
  Write of size 8 at addr ffff8880047cdc38 by task init/1
   lock_sock_nested (net/core/sock.c:3839)
   tipc_release (net/tipc/socket.c:638)
   __sock_release (net/socket.c:710)
   sock_close (net/socket.c:1501)
   __fput (fs/file_table.c:512)
  Allocated by task 1:
   sk_alloc (net/core/sock.c:2308)
   tipc_sk_create (net/tipc/socket.c:487)
   tipc_accept (net/tipc/socket.c:2744)
   do_accept (net/socket.c:2034)
  Freed by task 1:
   __sk_destruct (net/core/sock.c:2391)
   tipc_sk_create (net/tipc/socket.c:504)
   tipc_accept (net/tipc/socket.c:2744)
   do_accept (net/socket.c:2034)

Fixes: 00aff35 ("net: tipc: fix possible refcount leak in tipc_sk_create()")
Cc: stable@vger.kernel.org
Reviewed-by: Tung Nguyen <tung.quang.nguyen@est.tech>
Reviewed-by: Breno Leitao <leitao@debian.org>
Signed-off-by: Daehyeon Ko <4ncienth@gmail.com>
Reviewed-by: Simon Horman <horms@kernel.org>
Link: https://patch.msgid.link/20260714131939.1255974-1-4ncienth@gmail.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Changed files:
  net/core/sock.c
  net/tipc/socket.c
  net/socket.c
  fs/file_table.c

Diff excerpt:

Not included in this email. See the upstream URL for the full patch.

Full patch:
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=b07d87b31631edb6529e6cdcca790a7489d1250d

======================================================================
DETAILED REPORT METHODOLOGY
======================================================================

The original Linux kernel CVE announcement for CVE-2026-68117 can be found here:
https://lore.kernel.org/linux-cve-announce/?q=CVE-2026-68117

The original CVE announcement normally does not include a security-level
estimate. In particular, it may not contain a CVSS assessment, an impact
level, or enough information to determine whether the reported bug is a
practically relevant security issue. One purpose of this parallel CVE list
is to provide that missing technical and prioritization information.

The original goal of the AL-KERNEL project was to prioritize Linux kernel
CVE analysis automatically before manual review. The system can also help
identify non-security issues that may be suitable for automatic closure.

This report was generated by AL-KERNEL, an AI-assisted Linux kernel
vulnerability analysis system developed by Alexander Larkin.

The first analysis stage combines an autonomous classifier with additional
LLM-based analysis. The autonomous classifier runs locally on a CPU and is
based on a backpropagation neural network. Together, these mechanisms
produce a technical vulnerability description, identify likely weakness
types, estimate CVSS severity, and provide input for ActionableScore.

Two CVSS estimates are retained because incomplete kernel vulnerability
information often permits more than one defensible interpretation:

  Conservative CVSS vector: AV:L/AC:H/PR:L/UI:N/S:U/C:L/I:L/A:H
  The Best / paranoid CVSS vector: AV:A/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H
  The Best / paranoid CVSS score: 7.5

The conservative vector represents a lower-impact interpretation.
The Best/paranoid vector intentionally represents a plausible upper-bound
interpretation and should not automatically be treated as demonstrated
real-world impact.

CVSS may also need to be adjusted for a particular Linux deployment,
because actual reachability, privileges, enabled kernel configuration,
hardware, namespaces, exposed device nodes, and other environmental
conditions can differ significantly between systems.

A separate ActionableScore mechanism evaluates practical remediation
urgency. Its analysis may include reachability, attack prerequisites,
subsystem exposure, memory-corruption characteristics, denial-of-service
reliability, and possible confidentiality, integrity, or
privilege-escalation impact.

  Conservative ActionableScore: 4
  Paranoid ActionableScore: 6

The final base severity is taken directly from the second tab-separated
field of the AL-KERNEL classification result. ActionableScore does not
replace or independently override that final AL-KERNEL decision, and
if ActionableScore adjusted impact level of ALKERNEL, then you would see
self-readable flags above like INCREASED_TO_HIGH_BASED_ON_ACTIONABLESCOREHIGHEREQTHAN7.

For an AL-KERNEL result of MODERATE, this report uses the following
additional presentation split:

  ActionableScore below 5   -> MODERATE REGULAR
  ActionableScore 5 or more -> MODERATE 7.0

The distinction between MODERATE REGULAR and MODERATE 7.0 makes it
possible to identify Moderate issues that should receive manual analysis
and fixes before lower-priority MODERATE REGULAR issues. In many cases,
MODERATE REGULAR fixes may wait for a later rebase or routine update.

There is one override in which MODERATE REGULAR becomes MODERATE 7.0
even when the ActionableScore is below 5. When the AL-KERNEL result
contains the KPANIC flag, a MODERATE result is always presented as
MODERATE 7.0. The KPANIC flag selected with few regexps without
usage of AI at all, so it helps to detect cases when Kernel Crash happens
and similar (to filter False-Negative results from the LLM usage).

KPANIC indicates that a reliable kernel crash, kernel panic, or similarly
serious kernel availability impact was identified by the classification
workflow.

AL-KERNEL base severity for this report: MODERATE
KPANIC detected for this report: YES
Published priority for this report (same as in Subject): MODERATE 7.0

These results are intended to support engineering triage. They are
machine-generated estimates, and cases marked for manual review should
be validated by a human security engineer before final disposition.
For more info read docs linked from here: https://kernelcve.org/
(and you can submit you own patch there to generate such a report
for non-existant CVE-id yet).

Note that in many cases this AI tool selects higher severity, than
real is (means you can expect Importants instead of Moderate 7.0 or
Moderates 7.0 instead of regular Moderates). If you see such cases,
please use reply email interface to add additional manual analyses
info to this particular CVE.
And please, please, let me know when you see Lows instead of Importants
or Important instead of Low (because particular for such cases I
need to tune this AI tool to make it better for this one and next similar).
My contact email for such notifications is alexanjelausa@gmail.com (and both
send reply to CVE record itself too and see "reply" button below for howto reply).