Re: CVE-2026-43284: xfrm: esp: avoid in-place decrypt on shared skb frags

[Tomasz Figa <tfiga@chromium.org>]

Hi Massimiliano,

On Fri, May 08, 2026 at 10:57:05AM +0200, Massimiliano Pellizzer wrote:
> On Fri, May 8, 2026 at 9:24 AM Greg Kroah-Hartman
> <gregkh@linuxfoundation.org> wrote:
> >
> > From: Greg Kroah-Hartman <gregkh@kernel.org>
> >
> > Description
> > ===========
> >
> > In the Linux kernel, the following vulnerability has been resolved:
> >
> > xfrm: esp: avoid in-place decrypt on shared skb frags
> >
> > MSG_SPLICE_PAGES can attach pages from a pipe directly to an skb. TCP
> > marks such skbs with SKBFL_SHARED_FRAG after skb_splice_from_iter(),
> > so later paths that may modify packet data can first make a private
> > copy. The IPv4/IPv6 datagram append paths did not set this flag when
> > splicing pages into UDP skbs.
> >
> > That leaves an ESP-in-UDP packet made from shared pipe pages looking
> > like an ordinary uncloned nonlinear skb. ESP input then takes the no-COW
> > fast path for uncloned skbs without a frag_list and decrypts in place
> > over data that is not owned privately by the skb.
> >
> > Mark IPv4/IPv6 datagram splice frags with SKBFL_SHARED_FRAG, matching
> > TCP. Also make ESP input fall back to skb_cow_data() when the flag is
> > present, so ESP does not decrypt externally backed frags in place.
> > Private nonlinear skb frags still use the existing fast path.
> >
> > This intentionally does not change ESP output. In esp_output_head(),
> > the path that appends the ESP trailer to existing skb tailroom without
> > calling skb_cow_data() is not reachable for nonlinear skbs:
> > skb_tailroom() returns zero when skb->data_len is nonzero, while ESP
> > tailen is positive. Thus ESP output will either use the separate
> > destination-frag path or fall back to skb_cow_data().
> >
> > The Linux kernel CVE team has assigned CVE-2026-43284 to this issue.
> >
> >
> > Affected and fixed versions
> > ===========================
> >
> >         Issue introduced in 6.5 with commit 7da0dde68486b2d5bd7c689a9b327b77efecdfd0 and fixed in 6.6.138 with commit 50ed1e7873100f77abad20fd31c51029bc49cd03
> >         Issue introduced in 6.5 with commit 7da0dde68486b2d5bd7c689a9b327b77efecdfd0 and fixed in 6.12.87 with commit b54edf1e9a3fd3491bdcb82a21f8d21315271e0d
> >         Issue introduced in 6.5 with commit 7da0dde68486b2d5bd7c689a9b327b77efecdfd0 and fixed in 6.18.28 with commit 71a1d9d985d26716f74d21f18ee8cac821b06e97
> >         Issue introduced in 6.5 with commit 7da0dde68486b2d5bd7c689a9b327b77efecdfd0 and fixed in 7.0.5 with commit 52646cbd00e765a6db9c3afe9535f26218276034
> >
> > 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-43284
> > 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/ipv4/esp4.c
> >         net/ipv4/ip_output.c
> >         net/ipv6/esp6.c
> >         net/ipv6/ip6_output.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/50ed1e7873100f77abad20fd31c51029bc49cd03
> >         https://git.kernel.org/stable/c/b54edf1e9a3fd3491bdcb82a21f8d21315271e0d
> >         https://git.kernel.org/stable/c/71a1d9d985d26716f74d21f18ee8cac821b06e97
> >         https://git.kernel.org/stable/c/52646cbd00e765a6db9c3afe9535f26218276034
> >         https://git.kernel.org/stable/c/f4c50a4034e62ab75f1d5cdd191dd5f9c77fdff4
> >
> 
> I tested the publicly available exploit against the stable kernel 5.15.204.
> That stable branch is affected too.
> 
> ```
> $ ./run.sh
> === Stage 1 — overwrite 'systemd-timesync' line (89 bytes) with
> 'sick::0:0:<pad>:/:/bin/bash'
> === Stage 2 — verify
> sick::0:0:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX:/:/bin/bash
> === Stage 3 — su - sick (empty password via PAM nullok)
> [i] state saved to /var/tmp/.cf2.state — run './run.sh --clean' to revert
> # whoami
> root
> # uname -r
> 5.15.204
> ```

First of all, thanks for testing. However, I don't see the support for
MSG_SPLICE_PAGES present in kernels 6.1 and older (i.e. 7da0dde68486
("ip, udp: Support MSG_SPLICE_PAGES") is not there in 6.1.y and older
stable branches).

Are you sure the PoC didn't fall back to the RxRPC Page-Cache Write
vulnerability in your case?

Besides that, looking at the backports to the kernels 6.1 and older,
they look very different compared to 6.6 and newer:

6.1

diff --git a/net/ipv4/ip_output.c b/net/ipv4/ip_output.c
index 79cf1385e8d24..ec8279278deae 100644
@@ -1463,6 +1463,8 @@ ssize_t	ip_append_page(struct sock *sk, struct flowi4 *fl4, struct page *page,
 			goto error;
 		}
 
+		skb_shinfo(skb)->tx_flags |= SKBFL_SHARED_FRAG;
+
 		if (skb->ip_summed == CHECKSUM_NONE) {
 			__wsum csum;
 			csum = csum_page(page, offset, len);

6.6

diff --git a/net/ipv4/ip_output.c b/net/ipv4/ip_output.c
index ff8040101193a..305d0e2786a2a 100644
--- a/net/ipv4/ip_output.c
+++ b/net/ipv4/ip_output.c
@@ -1230,6 +1230,8 @@ alloc_new_skb:
 			if (err < 0)
 				goto error;
 			copy = err;
+			if (!(flags & MSG_NO_SHARED_FRAGS))
+				skb_shinfo(skb)->flags |= SKBFL_SHARED_FRAG;
 			wmem_alloc_delta += copy;
 		} else if (!zc) {
 			int i = skb_shinfo(skb)->nr_frags;

Note that in the 6.6 case the SKBFL_SHARED_FRAG is only set conditionally for
the MSG_SPLICE_PAGES case, but for in the 6.1 version it's set unconditionally
for any fragment. Is this expected?

Best,
Tomasz