From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: linux-cve-announce@vger.kernel.org
Cc: Greg Kroah-Hartman <gregkh@kernel.org>
Subject: CVE-2026-80848: xfrm: espintcp: fix UAF during close
Date: Fri, 4 Sep 2026 17:53:15 +0200 [thread overview]
Message-ID: <2026090459-CVE-2026-80848-3987@gregkh> (raw)
From: Greg Kroah-Hartman <gregkh@kernel.org>
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.
The Linux kernel CVE team has assigned CVE-2026-80848 to this issue.
Affected and fixed versions
===========================
Issue introduced in 5.6 with commit e27cca96cd68fa2c6814c90f9a1cfd36bb68c593 and fixed in 5.10.269 with commit 29121c5e6591da527e8e36ddac7120dc527f574d
Issue introduced in 5.6 with commit e27cca96cd68fa2c6814c90f9a1cfd36bb68c593 and fixed in 5.15.220 with commit ed5d9102190c45fc70121c036b0626b740040b75
Issue introduced in 5.6 with commit e27cca96cd68fa2c6814c90f9a1cfd36bb68c593 and fixed in 6.1.187 with commit 4bc0dfa28dca6fc0084203732695968049c44072
Issue introduced in 5.6 with commit e27cca96cd68fa2c6814c90f9a1cfd36bb68c593 and fixed in 6.6.156 with commit ff8dd7a932f34409a56e1b91a1219340f17457e9
Issue introduced in 5.6 with commit e27cca96cd68fa2c6814c90f9a1cfd36bb68c593 and fixed in 6.12.108 with commit 4b31a875693c480c611519faca46216514e3e052
Issue introduced in 5.6 with commit e27cca96cd68fa2c6814c90f9a1cfd36bb68c593 and fixed in 6.18.49 with commit 24efebecf415ba264adba0f0491cec436463a14f
Issue introduced in 5.6 with commit e27cca96cd68fa2c6814c90f9a1cfd36bb68c593 and fixed in 7.1.13 with commit eb3bbf29c723fe75c0eb92be14f0ec92971fe272
Issue introduced in 5.6 with commit e27cca96cd68fa2c6814c90f9a1cfd36bb68c593 and fixed in 7.2.3 with commit 54b41ad14da9a981131ab6e4d3f79321a503ea5d
Issue introduced in 5.6 with commit e27cca96cd68fa2c6814c90f9a1cfd36bb68c593 and fixed in 7.3-rc1 with commit deb232e884877bf10b4ce2580909eedec986c284
Please see https://www.kernel.org for a full list of currently supported
kernel versions by the kernel community.
Unaffected versions might change over time as fixes are backported to
older supported kernel versions. The official CVE entry at
https://cve.org/CVERecord/?id=CVE-2026-80848
will be updated if fixes are backported, please check that for the most
up to date information about this issue.
Affected files
==============
The file(s) affected by this issue are:
net/xfrm/espintcp.c
Mitigation
==========
The Linux kernel CVE team recommends that you update to the latest
stable kernel version for this, and many other bugfixes. Individual
changes are never tested alone, but rather are part of a larger kernel
release. Cherry-picking individual commits is not recommended or
supported by the Linux kernel community at all. If however, updating to
the latest release is impossible, the individual changes to resolve this
issue can be found at these commits:
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
reply other threads:[~2026-09-04 16:00 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2026090459-CVE-2026-80848-3987@gregkh \
--to=gregkh@linuxfoundation.org \
--cc=cve@kernel.org \
--cc=gregkh@kernel.org \
--cc=linux-cve-announce@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.