CyberSecBulletin
CVE-2026-68117NVD status: Received

Linux: Use After Free

CVE-2026-68117 is a critical-severity use after free vulnerability in Linux, with a CVSS 3.1 base score of 9.8 out of 10. It can be exploited remotely over the network by an unauthenticated attacker, without any action from a user. The record lists versions efebc23e9b29e3e5a9e2127dd066929f7f0d315e, 8d6f26d48e61ef34f1921289401dbf36b10816af, 82f59aa27f33bd014a7d8739371ab5712d15e33b as the first without the flaw, so updating Linux to one of those releases or later removes the exposure. There is no confirmed exploitation so far. EPSS estimates a 0.53% chance of exploitation within 30 days, which is low compared with other CVEs.

Patch this week

Critical severity: a successful attack would have severe impact.

What to do

  1. Update Linux to efebc23e9b29e3e5a9e2127dd066929f7f0d315e or 8d6f26d48e61ef34f1921289401dbf36b10816af or 82f59aa27f33bd014a7d8739371ab5712d15e33b or b07d87b31631edb6529e6cdcca790a7489d1250d, whichever matches your release line, or a later version.
  2. Until you can update, restrict network access to the affected service so it is not reachable from untrusted networks.

Affected products and versions

VendorProductAffected versionsFixed in
LinuxLinuxefa78f2ae363428525fb4981bb63c555ee79f3c7 up to, but not including, efebc23e9b29e3e5a9e2127dd066929f7f0d315e; 833ecd0eae76eadf81d6d747bb5bc992d1151867 up to, but not including, 8d6f26d48e61ef34f1921289401dbf36b10816af; 00aff3590fc0a73bddd3b743863c14e76fd35c0c up to, but not including, 82f59aa27f33bd014a7d8739371ab5712d15e33b; 00aff3590fc0a73bddd3b743863c14e76fd35c0c up to, but not including, b07d87b31631edb6529e6cdcca790a7489d1250d; 00aff3590fc0a73bddd3b743863c14e76fd35c0c up to, but not including, dd29891ed840f6b8d020b759d0dc4a00b1d6e4ea; 00aff3590fc0a73bddd3b743863c14e76fd35c0c up to, but not including, 5f5a41a48dbf9eda57b67ce23e548602cf7195a6; 00aff3590fc0a73bddd3b743863c14e76fd35c0c up to, but not including, f9596b1566616a8be0592dbceccb6344a7c6f6bb; 00aff3590fc0a73bddd3b743863c14e76fd35c0c up to, but not including, ba0533fc163f905fe817cfabdf8ed4058da44800; and 13 more rangesefebc23e9b29e3e5a9e2127dd066929f7f0d315e, 8d6f26d48e61ef34f1921289401dbf36b10816af, 82f59aa27f33bd014a7d8739371ab5712d15e33b, b07d87b31631edb6529e6cdcca790a7489d1250d, dd29891ed840f6b8d020b759d0dc4a00b1d6e4ea, 5f5a41a48dbf9eda57b67ce23e548602cf7195a6

Version data comes from the organisation that assigned the CVE. Confirm against the vendor advisory before deciding you are unaffected.

How the severity score breaks down

Attack vector
NetworkCan be exploited remotely over a network, including the internet.
Attack complexity
LowNo special conditions are needed; the attack works reliably.
Privileges required
NoneNo account or login is needed.
User interaction
NoneNo action by a victim is required.
Scope
UnchangedImpact stays within the vulnerable component.
Confidentiality
HighAll data handled by the component can be read.
Integrity
HighData or code can be modified at will.
Availability
HighThe component can be taken down completely.

Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H. Scored by CNA.

Official description

In the Linux kernel, the following vulnerability has been resolved: tipc: clear sock->sk on the failed-insert path in tipc_sk_create() 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)

Source: the CVE record as published by its numbering authority, via NVD and CVE.org.

The underlying weakness: Use After Free

The product reuses or references memory after it has been freed. At some point afterward, the memory may be allocated again and saved in another pointer, while the original pointer references a location somewhere within the new allocation. Any operations using the original pointer are no longer valid because the memory belongs to the code that operates on the new pointer.

How developers prevent this class of flaw

  • Choose a language that provides automatic memory management.
  • When freeing pointers, be sure to set them to NULL once they are freed. However, the utilization of multiple or complex data structures may lower the usefulness of this strategy.

More Use After Free vulnerabilities (CWE-416)

Timeline

  1. CVE record published.
  2. CISA published its SSVC assessment (exploitation: none, automatable: yes, technical impact: total).
  3. Record last changed materially (score, affected products, status or references).

References

Recent Use After Free vulnerabilities

Spotted an error? Tell us.