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.
Fix
Nothing published yet: no patch, vendor advisory or mitigation reference on NVD, no vendor advisory in the News for this CVE, not in CISA's KEV, no fixed package version. BaselineWatch does not guess at one.
Change history 2
- StatusReceived → PublishedNVD modified 2026-10-19 08:44
- First seenunscoredNVD modified 2026-10-19 09:17
Affected (CPE criteria) 0
NVD has not attached CPE configurations yet.
References 9
- https://git.kernel.org/stable/c/24efebecf415ba264adba0f0491cec436463a14f
- https://git.kernel.org/stable/c/29121c5e6591da527e8e36ddac7120dc527f574d
- https://git.kernel.org/stable/c/4b31a875693c480c611519faca46216514e3e052
- https://git.kernel.org/stable/c/4bc0dfa28dca6fc0084203732695968049c44072
- https://git.kernel.org/stable/c/54b41ad14da9a981131ab6e4d3f79321a503ea5d
- https://git.kernel.org/stable/c/deb232e884877bf10b4ce2580909eedec986c284
- https://git.kernel.org/stable/c/eb3bbf29c723fe75c0eb92be14f0ec92971fe272
- https://git.kernel.org/stable/c/ed5d9102190c45fc70121c036b0626b740040b75
- https://git.kernel.org/stable/c/ff8dd7a932f34409a56e1b91a1219340f17457e9