CVE-2026-80848: xfrm: espintcp: fix UAF during close
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:
espintcpclose() frees emsg->skb via kfreeskb() without holding any socket lock. Concurrently, the xfrmtransreinject work queue invokes espoutputtcpfinish() -> espintcppushskb() -> espintcppushmsgs() -> skbsendsocklocked(), which reads the same skb as a data source.
Fix this by adding a synchronizercu() call after resetting skprot, since espoutputtcpfinish() runs under RCU and won't use a socket with skprot == &tcpprot. Simply taking the socket lock in espintcpclose() could lead to leaks, if espoutputtcpfinish() re-adds an skb in the slot we just freed. After this, the existing barrier() is no longer needed.
Affected Software
Event History
Frequently Asked Questions
What condition is required to trigger this issue?
The issue requires a race while an espintcp socket is closing: the close path frees an skb while concurrent xfrm_trans_reinject work processes that same skb through esp_output_tcp_finish().
Which systems are exposed?
Linux kernel systems using espintcp sockets are relevant. The provided information does not identify affected kernel versions or state whether espintcp is enabled by default.
What does the fix change?
The fix resets sk_prot and then waits with synchronize_rcu() before freeing the skb. This prevents RCU-protected esp_output_tcp_finish() processing from using the socket after its protocol has been switched back to tcp_prot.