From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pl1-f169.google.com (mail-pl1-f169.google.com [209.85.214.169]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 4E50C26ED4F for ; Sat, 9 May 2026 10:40:32 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.169 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778323234; cv=none; b=UKXWfNKGDZghzzigsvHauCjH2NbFBNDT/TzLad3rlS6zXAegUDBTxMmghxIVqgQk6zNjwn4SYodqJjOlOxtmrrHLlsPepDU7xrjp56+hJI6IDfFekFF1JpKFW0sL4+R+oP8iePtH58VzuMpgfVfcjtcRfzAJXhsx44Ywu9v8zVg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778323234; c=relaxed/simple; bh=Inge0WNQFcfq5tC2+s0WdBYHcwB1uqYXEBnhPbxFTqk=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=Smx7cIhQ6eEBmMESriKAuRzzERoCqmMyLTLtXZtLLh08wQhM7YUpwDtEQONPEBr9abDI4/aRFtbWE1wxsSGbhiyF+/YdBrgz8wO6NM88sFeSUYYD1xn0f2hhy8EiidkkfdAP6mNkc3chfK/ofFACKtXuyaX6ZcCZYl3l1OT6bh0= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=chromium.org; spf=pass smtp.mailfrom=chromium.org; dkim=pass (1024-bit key) header.d=chromium.org header.i=@chromium.org header.b=GiI3l2tc; arc=none smtp.client-ip=209.85.214.169 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=chromium.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=chromium.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=chromium.org header.i=@chromium.org header.b="GiI3l2tc" Received: by mail-pl1-f169.google.com with SMTP id d9443c01a7336-2b45cb89f7eso18844725ad.0 for ; Sat, 09 May 2026 03:40:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; t=1778323232; x=1778928032; darn=vger.kernel.org; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=oTF/iEb+L47LdjQfGZ+s3256+hRViTdBsJvmGj7BRpU=; b=GiI3l2tcelMGRPzae8e1g511hiZZDfF7b8Ypne/bHcN9yaGL0Q+OFqTX6JuTnldAap 95wOwzU1emHjTEeFh09PHHCLmvXKUmNH/qvll0vGBfPqZVgURTLOtpYMfUOdmgWoiXsi a2EPTp61fFyyhHOQINWxBMIMEXYoLBJWTINJs= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1778323232; x=1778928032; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=oTF/iEb+L47LdjQfGZ+s3256+hRViTdBsJvmGj7BRpU=; b=Pz/JlNVHjCMJWQBRkjBtjd6VJPPQKb4QI/IwDTeymI5FuHpZBC3fWEIZ0LgwMalPKK C+DszhgJkLqzsyTDRkEhBd9GlTluU6CS4/of+k8YVBHRrvvLoo4rnQvBlPAWGyvfStW1 G9Z6yv7Ygh6xx4jCQJ8SYFvHWazSZW0d1J38p5Mi1vfpFaxi/ESaBTdPAcJ/IRdN11u0 bQvLjAgmzorgQ1B8SCdktLImensp1FiLHt/K20MlmmSRsetzJPP13hQQKkF0yiaWVPHz bolSAXGCcOlFYHsQ1D42zmtEMKI2S81ErCxvKZOCPmomaGjgicyoXCEbHDt0jk8orwRV vxtQ== X-Forwarded-Encrypted: i=1; AFNElJ/MP2WrBaMzhyU9KzDQtanYEZ6SfLwGOxXpKoaR56Icb5VBKjzQlCWuklUWrQCT+5c+F7xwmqsX6/n0ba8=@vger.kernel.org X-Gm-Message-State: AOJu0YySWCZQhvl0tZGobjR5sQ4ljDmeI+v/EGxOMOn2BNLcZmenlfZH Mye0qO/gI5OWMSnp1uJOmftwVDIumjF47zJBpktYfrPwatUksElnQ/SVfq0qdm2K2Q== X-Gm-Gg: Acq92OFCfng2/XpAwqWWLUznnFMbwVArZOxCGwvyFYK1GwZjsXxgzPBJP43YvjbPz8z wFUPrk4qlifVzlItz3HPnqPHKNMLhnk+HQOoUmVlfN00hjuN/NYB8tfd3WN88i8QXFMv6YKZXGM GQmphVnlG/KdQYZjjYvcP0bLnsRWBG9AwvffOijtavVwILooBeV0npOI2peNtzyvsSHFHV+6a9h FrnjZjwumvOG6L8CgOweHfQCgaNBjsP80in52EDKhpPqYnGczPIZRxBv91xvRXXy5Uhp2EIPczR 7+Oqh35m85Si6SAcQSW0xAzZ4FgYZTguoX7hoH1GEi7bKc8GTnyLknVp+L5kEFyGezBFBFCyFHQ mfLetEmxyJqo0Y3TFcNXUriM0HOJDpHAriynQKAqxccEvSoX8LZQILI/Tv8LBXrA7BgiWLQzLiQ Xs3Q7IxzzwChywQRInc1H0I6ay5cl/kFr0bNJMs8dk3iKlVR9kKldE3pI4Nh6w X-Received: by 2002:a17:903:f85:b0:2bc:90f7:fbbc with SMTP id d9443c01a7336-2bc90f7fc5cmr3492625ad.39.1778323230561; Sat, 09 May 2026 03:40:30 -0700 (PDT) Received: from chromium.org (35.198.80.34.bc.googleusercontent.com. [34.80.198.35]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-2baf1ec232esm49866005ad.81.2026.05.09.03.40.28 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 09 May 2026 03:40:30 -0700 (PDT) Date: Sat, 9 May 2026 19:40:26 +0900 From: Tomasz Figa To: Massimiliano Pellizzer , Greg Kroah-Hartman Cc: cve@kernel.org, linux-kernel@vger.kernel.org Subject: Re: CVE-2026-43284: xfrm: esp: avoid in-place decrypt on shared skb frags Message-ID: References: <2026050856-CVE-2026-43284-6598@gregkh> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: 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 > wrote: > > > > From: Greg Kroah-Hartman > > > > 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::/:/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