From nobody Mon Jun 8 07:24:46 2026 Received: from mail-wm1-f43.google.com (mail-wm1-f43.google.com [209.85.128.43]) (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 F091946AEF5 for ; Wed, 3 Jun 2026 11:45:34 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.43 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780487138; cv=none; b=FIJpwH3u8eSpmASN4BATjUJUBfh9oCBEICSxyXyNnMGTqLoAogt5FqLV/7xNOZOAattwAdROMDswlQqRDlxrG4fdfx8Y/vlXKrJ3fpD2ooM1o2tNW8EzyF34sMM8IMC9lorbx4jChixHfviWp0Hf4bUPbAccOUb6LKABwbyXo9o= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780487138; c=relaxed/simple; bh=gd5vDE0EgC5Y/TloUUjWllfVdY/CPpj1lgzm/vFa0Oo=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=SBJWyoeKxN1nG2icbpjslpgkm2LiuAmvt/VeV2+AzJt8qKsTV+NJdzkEPaDSse/2orHXXDkZdI1lyVAo170mqoFSu+Kvf/n4IecgjywIQFEtwBVI01t8nbnUgeXDxtZskPhOizUcsdY39iMcA1eXVMC+iiz3ZQZsNfLNjRfFYcA= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=lJmjFgXP; arc=none smtp.client-ip=209.85.128.43 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="lJmjFgXP" Received: by mail-wm1-f43.google.com with SMTP id 5b1f17b1804b1-490b7866869so7179545e9.2 for ; Wed, 03 Jun 2026 04:45:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1780487133; x=1781091933; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=u8HLA5Iqrs8aKSaat9xrCrQaPXrAkc97UqyJ91X2+cQ=; b=lJmjFgXPFt6SsHWHSgMJdO6OfeQHCP9wMJzxZyrFmAtn0slT3pOYrMotcuPA45zV50 dDo1Z7qwowvi0anooRf5D6f+NSvwbs9dBGg/pdWZIoX5bjBWVbG47+3ws0ofXSiB/iQW z5gtUVujeSIeF7zjI0DQ7fiXuWLWsjEdPbgvvX88VS9I5rxhh0gyT8G+RdWy+Sd+GF9c cjbHMwKTzlV0u5KnKpcI/6V9v6gVFll6SkkW4uYRyjk8onyTiwMdgfWmETXkv3Yps1qg Wuve5CenqaCpGIxF3BJ4LXMCgO4HWcH7Q2lNHFEUnI28jNn7Te3s0goILiAR0aUHKsiP mKLQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1780487133; x=1781091933; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=u8HLA5Iqrs8aKSaat9xrCrQaPXrAkc97UqyJ91X2+cQ=; b=IdXII10eMhobbbY06oeB8GJmtByf5NxxYX6TXavJjgA6B1ZB/R9KYX26aeoappST2O ykyEAhG4wDswWh6VzcoazcTbjvSp1Ggn+JV6rcu3OIyvyBNZTg/7gHj5MLp0k/wJ0OMp lp1ov/n3NFEG5KHYJGdkgAcr6alkYxcgRaTHmII0Ulu6MNWguF8AhA9ymvBRJ2WeX/jK y2bBoTnUAET845+mmhY/uAWrP/o60zUMBfu7+E1mC9g7betncHDNMc6y1x3ORYF3KC6w Ut5iALOyu5WpqyFwYoUMM4T88g4iomhvtYHgU6t9v9datgaBTXKQczEdacqGht+zldWW ZeQw== X-Forwarded-Encrypted: i=1; AFNElJ8jwra9/KnnP+lW/UFd3lD7DJJ4QTGyXyLxNVNunZLz3/JVvstKI/G3mW6X2zk3IIm3kuhHTdT99xMSa8w=@vger.kernel.org X-Gm-Message-State: AOJu0Yy3C3e6fr+BdgtpWZRCTG/5OsGeqAufmI1oQfQqGDm8SoEVHIxK xt1ct2RTc8Vo7QJRcEzA1nuaGhWI4xUkGBed+5XFWmjpqHykSlzGvWo6 X-Gm-Gg: Acq92OGauxwd+y8NSlGqwHt7yIhIhEO5ZpveA6OT3sNmNC9R/SZxsUYiTLC+kFLEUZF 3xUBrEWZVd9Ywnxn/EJffQrxY02t3hVQlbNe8KFLg/g7TMTM/4jNjsTOUPLVNflXGR9sEaMMz6F pNmBDlCPqeR9DCBiiewjgExdNW4UGXDEwCpnY9BOrOi5ESVBG6lR/U4SIcLNNj/kdSHTtRRG2oA VbnkuEesuFm1+AyjstoCEO5ZD99z5SrfDrYBUzeb8Eej+Ae2XA698EAeaRX3vC82RmR77su4xVG RbtbNhnICj4wCUK3Fcjk/fm2TvggpzD2bZnIiZWjADi2h/FQRfmYDmpq/i7VSWH+ay1O5eYIbc/ PohXcQo9Nwky4GtQ6XJideyVPx10t68KILpLy0e+nAwvW6uVHAcCVe5CjidupJMVy/TX/mSlHkc awYhBOUwUQFmB5zaDQpa52ZmbnjPZN8/IpB8ymN8t3WqywDC855SzxQZwCo5TZSEtIzk6jWnAFL /ZrEVpMUYNCOpVx3w== X-Received: by 2002:a05:600c:4e0a:b0:489:1c32:210d with SMTP id 5b1f17b1804b1-490b5fd8a86mr52359605e9.15.1780487133034; Wed, 03 Jun 2026 04:45:33 -0700 (PDT) Received: from localhost.localdomain ([2a01:827:3b28:500:30ab:2400:2a9c:6742]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-490b616d6a9sm54244165e9.7.2026.06.03.04.45.32 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 03 Jun 2026 04:45:32 -0700 (PDT) From: Alessandro Schino <7991aleschino@gmail.com> To: netdev@vger.kernel.org Cc: steffen.klassert@secunet.com, herbert@gondor.apana.org.au, davem@davemloft.net, pabeni@redhat.com, linux-kernel@vger.kernel.org, Alessandro Schino <7991aleschino@gmail.com> Subject: [PATCH ipsec v2] esp: fix page frag reference leak on skb_to_sgvec failure Date: Wed, 3 Jun 2026 13:45:07 +0200 Message-ID: <20260603114507.1443-1-7991aleschino@gmail.com> X-Mailer: git-send-email 2.41.0.windows.3 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" In esp_output_tail(), when esp->inplace is false, the old skb page frags are replaced with a new page from the xfrm page_frag cache. The source scatterlist (sg) is built from the old frags before the replacement, and esp_ssg_unref() is responsible for releasing the old page references after the crypto operation completes. However, if the second skb_to_sgvec() call (which builds the destination scatterlist from the new page) fails, the code jumps to error_free which only calls kfree(tmp). The old page frag references captured in the source scatterlist are never released: 1. sg[] is built from old frags via skb_to_sgvec() (no extra get_page) 2. nr_frags is set to 1 and frag[0] is replaced with the new page 3. Second skb_to_sgvec() fails -> goto error_free Fix this by adding a bool parameter to esp_ssg_unref() that, when true, unconditionally unrefs the source scatterlist frags. Since req->src is not yet initialized by aead_request_set_crypt() at the point of the error, the source scatterlist is obtained directly via esp_req_sg(). Existing callers pass false to preserve the original behavior. The same issue exists in both esp4 and esp6 as the code is identical. Fixes: cac2661c53f3 ("esp4: Avoid skb_cow_data whenever possible") Fixes: 03e2a30f6a27 ("esp6: Avoid skb_cow_data whenever possible") Signed-off-by: Alessandro Schino <7991aleschino@gmail.com> --- v2: split the long line in esp_ssg_unref() to keep it under 100 columns net/ipv4/esp4.c | 7 +++++-- net/ipv6/esp6.c | 7 +++++-- 2 files changed, 10 insertions(+), 4 deletions(-) diff --git a/net/ipv4/esp4.c b/net/ipv4/esp4.c index 2429c7845984..dfc81ee969ae 100644 --- a/net/ipv4/esp4.c +++ b/net/ipv4/esp4.c @@ -113,10 +113,13 @@ static void esp_ssg_unref(struct xfrm_state *x, void = *tmp, struct sk_buff *skb, /* Unref skb_frag_pages in the src scatterlist if necessary. * Skip the first sg which comes from skb->data. */ - if (already_unref || req->src !=3D req->dst) - for (sg =3D sg_next(already_unref ? esp_req_sg(aead, req) : req->src); s= g; sg =3D sg_next(sg)) + if (already_unref || req->src !=3D req->dst) { + struct scatterlist *src =3D already_unref ? esp_req_sg(aead, req) : req-= >src; + + for (sg =3D sg_next(src); sg; sg =3D sg_next(sg)) skb_page_unref(page_to_netmem(sg_page(sg)), skb->pp_recycle); + } } =20 #ifdef CONFIG_INET_ESPINTCP diff --git a/net/ipv6/esp6.c b/net/ipv6/esp6.c index 50af6ab9b8fc..296b57926abb 100644 --- a/net/ipv6/esp6.c +++ b/net/ipv6/esp6.c @@ -130,10 +130,13 @@ static void esp_ssg_unref(struct xfrm_state *x, void = *tmp, struct sk_buff *skb, /* Unref skb_frag_pages in the src scatterlist if necessary. * Skip the first sg which comes from skb->data. */ - if (already_unref || req->src !=3D req->dst) - for (sg =3D sg_next(already_unref ? esp_req_sg(aead, req) : req->src); s= g; sg =3D sg_next(sg)) + if (already_unref || req->src !=3D req->dst) { + struct scatterlist *src =3D already_unref ? esp_req_sg(aead, req) : req-= >src; + + for (sg =3D sg_next(src); sg; sg =3D sg_next(sg)) skb_page_unref(page_to_netmem(sg_page(sg)), skb->pp_recycle); + } } =20 #ifdef CONFIG_INET6_ESPINTCP --=20 2.41.0.windows.3