Strix
63.3K

CVE-2026-80848

Unknown

Last modified

CVE-2026-80848 is a vulnerability of currently unknown severity. 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.

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.

Affected Software

Source: CNA advisory (CVE.org). NVD analysis pending.

VendorProductVersions
LinuxLinux>= e27cca96cd68fa2c6814c90f9a1cfd36bb68c593, < 29121c5e6591da527e8e36ddac7120dc527f574d; >= e27cca96cd68fa2c6814c90f9a1cfd36bb68c593, < ed5d9102190c45fc70121c036b0626b740040b75; >= e27cca96cd68fa2c6814c90f9a1cfd36bb68c593, < 4bc0dfa28dca6fc0084203732695968049c44072; >= e27cca96cd68fa2c6814c90f9a1cfd36bb68c593, < ff8dd7a932f34409a56e1b91a1219340f17457e9; >= e27cca96cd68fa2c6814c90f9a1cfd36bb68c593, < 4b31a875693c480c611519faca46216514e3e052; >= e27cca96cd68fa2c6814c90f9a1cfd36bb68c593, < 24efebecf415ba264adba0f0491cec436463a14f; >= e27cca96cd68fa2c6814c90f9a1cfd36bb68c593, < eb3bbf29c723fe75c0eb92be14f0ec92971fe272; >= e27cca96cd68fa2c6814c90f9a1cfd36bb68c593, < 54b41ad14da9a981131ab6e4d3f79321a503ea5d; >= e27cca96cd68fa2c6814c90f9a1cfd36bb68c593, < deb232e884877bf10b4ce2580909eedec986c284
LinuxLinux5.6

References

Timeline

Published
Last Modified
Status
Received

Frequently Asked Questions

What is CVE-2026-80848?
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.
How severe is CVE-2026-80848?
Severity scoring for CVE-2026-80848 is pending analysis.
How do I fix CVE-2026-80848?
Check the vendor references and advisories linked above for patched versions and mitigation guidance. You can also run a Strix scan to test if your systems are affected.

How Strix Helps

Related CVEs from 2026

View all 2026CVEs →

Are you affected by CVE-2026-80848?

Run a free Strix scan to check your systems for this vulnerability.

Scan your code now

Source: NVD / NIST