Cloudanix VulnDB

CVE-2026-80848

None

CVSS

—

EPSS

0.2%

Published

Sep 4, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A bug in the Linux kernel's handling of certain encrypted network connections could let a local attacker crash the system or gain elevated privileges.

Exploitation
Local Privilege
Attacker needs
Local User
Complexity
Moderate
Impact
Privilege Gain
Component
OS kernel
Class
Use After Free
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

Use-after-free in the Linux kernel espintcp implementation: espintcp_close() frees an skb without holding the socket lock while the xfrm_trans_reinject work queue can concurrently invoke esp_output_tcp_finish() o espintcp_push_skb() o espintcp_push_msgs() o skb_send_sock_locked() on the same skb.

Why it matters to the business

Linux systems performing IPsec ESP over TCP may experience kernel crashes, memory corruption, or local privilege escalation, leading to service disruption or full host compromise.

How an attack unfolds

An attacker with local access triggers rapid espintcp socket close operations while the xfrm_trans_reinject work queue is active, racing the kfree_skb() in close against skb access in espintcp_push_msgs() to trigger the use-after-free.

How to fix it

Upgrade to a Linux kernel containing the synchronize_rcu() call after resetting sk_prot in the espintcp close path; rebuild and reboot affected systems.

How to confirm the fix worked

Verify the presence of the synchronize_rcu() fix in the kernel source for espintcp_close(), confirm sk_prot reset occurs before any RCU readers can access the socket, and test that espintcp sockets close cleanly under concurrent xfrm work queue load.

Typical attack path

  1. Obtain local code execution on a Linux host using espintcp sockets
  2. Open and rapidly close multiple espintcp sockets while IPsec traffic is active
  3. Race the close path against the xfrm_trans_reinject work queue
  4. Trigger use-after-free to corrupt kernel memory or redirect execution

How to detect it

Inspect kernel logs for oops/panic messages referencing espintcp_close, espintcp_push_msgs, xfrm_trans_reinject, or skb_send_sock_locked; correlate with process activity opening and closing espintcp sockets.

What your security team should do

  • Prioritize kernel upgrades on all systems exposing IPsec ESP/TCP sockets
  • Monitor for kernel oops or use-after-free reports involving espintcp or xfrm_trans_reinject
  • Apply the fix within standard patch windows given low EPSS and no KEV listing

The record

In the Linux kernel, the following vulnerability has been resolved: xfrm: espintcp: fix UAF during close ZDI reported and analyzed a race condition during close for espintcp sockets: espintcp_close() frees emsg->skb via kfree_skb() without holding any socket lock. Concurrently, the xfrm_trans_reinject work queue invokes esp_output_tcp_finish() -> espintcp_push_skb() -> espintcp_push_msgs() -> skb_send_sock_locked(), which reads the same skb as a data source. Fix this by adding a synchronize_rcu() call after resetting sk_prot, since esp_output_tcp_finish() runs under RCU and won't use a socket with sk_prot == &tcp_prot. Simply taking the socket lock in espintcp_close() could lead to leaks, if esp_output_tcp_finish() re-adds an skb in the slot we just freed. After this, the existing barrier() is no longer needed.

Affected packages

Ecosystem Package Introduced Fixed