From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr1-f43.google.com (mail-wr1-f43.google.com [209.85.221.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 7399D43D4F7 for ; Mon, 17 Aug 2026 13:38:01 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.43 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786973885; cv=none; b=PR55hNn7rJ9hv4d1nQwlL6Dvs7U52cLvXqGoZBYVem0Whs5hV10YVVXWoM2fsTZSbTNOtmk9k+c0WDc/Uh/v1RPD7nW8ixUghmkV5ej4Q5YUUzI13euHOnpIUJVZlLGVHOY/+BwmiaQr2/kvsGG1GqGjcmW69EDJig69+CMgIwU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786973885; c=relaxed/simple; bh=CC3JC1giahHEy9sjcaKvgoScSXSfuw8gg/e6vEdqmPA=; h=From:To:Cc:Subject:Date:Message-Id:MIME-Version; b=U35AAQv27VEp0fwn6LtTdrBKvEckgqMDRR6FTbI2bHKHR/UNZ/xqiggIGE6tBznif8AQAeQcrz1cgm09lbfZxCLnwwq4c2IM5N6o4suOflxgndITU+e1PVk3mDuS3NZ/R0Jlfqjtsfkv+jHxyobqhgB00Xl4S/HMmQFQ5uI1Wrg= 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=jeGhDhTq; arc=none smtp.client-ip=209.85.221.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="jeGhDhTq" Received: by mail-wr1-f43.google.com with SMTP id ffacd0b85a97d-47fe377a217so2314959f8f.1 for ; Mon, 17 Aug 2026 06:38:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1786973878; x=1787578678; 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:content-type; bh=zkp4KPcClMvoNogOQGnOerubTOxqG8PDXc/dySr0Dq4=; b=jeGhDhTqfvnk214WxoFyBMeeAjQQ0rbtnLUvA/VkTvw+sRnX1d8IfItV83IzxzdJXS EGP6O+O2ckNQFagqlDfr0uqumIHAblBmGtJ5Pyl/xdBopTEJg/ju/rzqZn3yfbQpNDAs 5f73QGykKjlNQMKEdkIOned/LvwoxpXuI2biZwgto/ehu1gOK8JD6VGZU2jO7XqwPLXU CwTGMbWEpuGTdK6pb1aw4Vn69T4tcuky7jnKIPxqgZrDtD291NFwfO9k1xQaE1rs2kkQ bRY3pEfHgHH+YfjFGO/zYQQSsHiRsjKVP80rc67NmKmRVt6L3RXqY2sR20pzRgaOuBb6 asMA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1786973878; x=1787578678; 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:content-type; bh=zkp4KPcClMvoNogOQGnOerubTOxqG8PDXc/dySr0Dq4=; b=NIdjbmIQpqgdBQfSxWfSa+ZXpi4hFvGUq/OD7oNigLgNVtt98XqZvkI2i5RpjfO982 g4TvLeHPWoteaiSdnKoKY8iAk1cSjrJZ9dSsL+ekuX56XI6glvAVzuCMZhzAoyUk2+gI um+g0DZTfLiETyPDSpE7ZyPCC6grnaTRpCJop2WRDC+/4Vak276FpUM0nHLe4dMpq3/n WMt3iQM9hi75EFZU6JPTsD8zRG4o5cdflyfwF/Akp/XcdesEe04HnVTEEvNE3i+tP2Fi bBAUtzjom+7dGrWEuSz7B0gVWfgVL36WKxZIZc90qp3XvotOK2XRHU5UKz7JE/f4KSNu DyJg== X-Forwarded-Encrypted: i=1; AHgh+RpN25uV5d62VktaDNLcuapF+si8KCGsIXShwVZfvfpWfe6qM+DgSdgZlnxjU5TjFLc4dRg6B6LsV96QEBk=@vger.kernel.org X-Gm-Message-State: AOJu0Yw5A94wfRGkbKxFng5kKpGOGWwY8CWiyhHG/VWPIFO4VIV7yF6e rL4K4O6Yum9zXkF3icf2GCnZp0dDpDy51QuY7o/gaZcO9dveZNtUkx9EC7x32ehs X-Gm-Gg: AR+sD11qQ4+ZCZES5h7stxcqAJhap/ovar2aWGPrPCU0lZJdGxCanRaUD7kbHrD+oe2 Cn0UiIAvw5s5bHNpaVoF9LWCkiA6T11hgA8OYBUBOIgejwvFvzz6LlajaboXkLa7wYCv+s2/jxe zF4jY0MnaWmF9HpO3WbRzrK85Rg+QvvchoqgE0p6a5Io6x6L9pmztUfluiN5xzK2UpAen42PO23 fvjPBqoFDPIxFmmYjE3vtpLjtw86IscC3J5/xIQRFCprijN51xtv3yHwHY4U3rJSCBUnBMUtzTM DDq+D3AyDFj+3aREPDF5FOUtS9gdxhXZco2YjEp5l3zWi/dpDqv6JIMQkCvNC3CIS0MVXpmv6US UHmabNsdkcVWN4qCbiwrlIZTq1CHZNNvr4Z8FnSdvckUlA/D85NR5pR9dysuQAF/FyimsiAm/M7 AJ7trR/aC/A7LHkfN5ffcQewvrhv2LviOk5gF4F52ApRNl8y6eH3a4eqr3D0vK09Aq8hfggwSR X-Received: by 2002:a05:6000:46d7:b0:47f:9447:62bf with SMTP id ffacd0b85a97d-482a8fea9e4mr389507f8f.2.1786973878093; Mon, 17 Aug 2026 06:37:58 -0700 (PDT) Received: from localhost.localdomain ([41.251.64.200]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-482a5b81715sm4141667f8f.35.2026.08.17.06.37.56 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 17 Aug 2026 06:37:57 -0700 (PDT) From: Maher Azzouzi To: steffen.klassert@secunet.com, herbert@gondor.apana.org.au Cc: davem@davemloft.net, edumazet@google.com, kuba@kernel.org, pabeni@redhat.com, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, Maher Azzouzi Subject: [PATCH net v2] esp: downgrade zerocopy managed frags before mutating skb frags Date: Mon, 17 Aug 2026 14:37:52 +0100 Message-Id: <20260817133752.30033-1-maherazz04@gmail.com> X-Mailer: git-send-email 2.34.1 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit On the out-of-place output path (esp->inplace == false) ESP rewrites the skb frag array: esp_output_head() appends a trailer frag and esp_output_tail() replaces the frags with a destination page, both referenced with get_page(). When the skb carries zerocopy managed frags (SKBFL_MANAGED_FRAG_REFS) the payload frags are owned by the ubuf and must not be referenced or unreferenced individually, but ESP mutates the frag array without ever downgrading the skb. This breaks the managed-frag invariant two ways: - esp_ssg_unref() walks the source scatterlist and drops a page reference for every frag, including the ubuf-owned payload frags, pushing their refcount below the GUP pin bias while the pages are still pinned, i.e. a use-after-free of the zerocopy pages; - esp_output_tail() installs its destination page as frag 0 with get_page() but leaves SKBFL_MANAGED_FRAG_REFS set, so skb_release_data() takes the skip_unref branch and never drops that reference, leaking the x->xfrag page at packet rate. Fix this the way every other frag-mutating site does (__ip_append_data(), __ip6_append_data(), tcp_sendmsg_locked()) and call skb_zcopy_downgrade_managed() before ESP touches the frag array: it takes a real reference on each existing frag and clears SKBFL_MANAGED_FRAG_REFS, so the per-frag unref in esp_ssg_unref() and the frag release in skb_release_data() are both balanced and no mixed-ownership frag array is left behind. Fixes: 753f1ca4e1e5 ("net: introduce managed frags infrastructure") Signed-off-by: Maher Azzouzi --- Changes in v2: - Use skb_zcopy_downgrade_managed() before ESP mutates the frag array, instead of the early return in esp_ssg_unref(). As pointed out in review, that early return also suppressed release of the ESP-owned trailer and destination page references (a leak); downgrading the skb the way __ip_append_data() does fixes both the underflow and the leak. - Fix the Fixes: tag - the bug needs managed frags (753f1ca4e1e5), not the 2017 skb_cow_data avoidance commits. v1: https://lore.kernel.org/netdev/20260712170530.9807-1-maherazz04@gmail.com/ net/ipv4/esp4.c | 6 ++++++ net/ipv6/esp6.c | 6 ++++++ 2 files changed, 12 insertions(+) diff --git a/net/ipv4/esp4.c b/net/ipv4/esp4.c index dfc81ee..faa48f5 100644 --- a/net/ipv4/esp4.c +++ b/net/ipv4/esp4.c @@ -441,6 +441,12 @@ int esp_output_head(struct xfrm_state *x, struct sk_buff *skb, struct esp_info * esp->inplace = false; + /* Take real page refs and clear SKBFL_MANAGED_FRAG_REFS before + * we mutate the frag array, so the per-frag unref stays balanced + * for zerocopy managed frags (see __ip_append_data()). + */ + skb_zcopy_downgrade_managed(skb); + allocsize = ALIGN(tailen, L1_CACHE_BYTES); spin_lock_bh(&x->lock); diff --git a/net/ipv6/esp6.c b/net/ipv6/esp6.c index 296b579..a3a3857 100644 --- a/net/ipv6/esp6.c +++ b/net/ipv6/esp6.c @@ -470,6 +470,12 @@ int esp6_output_head(struct xfrm_state *x, struct sk_buff *skb, struct esp_info esp->inplace = false; + /* Take real page refs and clear SKBFL_MANAGED_FRAG_REFS before + * we mutate the frag array, so the per-frag unref stays balanced + * for zerocopy managed frags (see __ip_append_data()). + */ + skb_zcopy_downgrade_managed(skb); + allocsize = ALIGN(tailen, L1_CACHE_BYTES); spin_lock_bh(&x->lock); -- 2.34.1