From: sashiko-bot@kernel.org
To: "Jakub Kicinski" <kuba@kernel.org>
Cc: bpf@vger.kernel.org
Subject: Re: [PATCH net 3/7] net: tls: fix page pin leak on sendpage_ok() failure
Date: Thu, 30 Apr 2026 22:31:30 +0000 [thread overview]
Message-ID: <20260430223131.33668C2BCB3@smtp.kernel.org> (raw)
In-Reply-To: <20260429222944.2139041-4-kuba@kernel.org>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Incomplete fix for page pin leak: dead code in the error path and a permanent leak on the success path for user-backed iterators.
--
commit 6f0253d94e63d44e6e53f2c84d2aead405564b2b
Author: Jakub Kicinski <kuba@kernel.org>
net: tls: fix page pin leak on sendpage_ok() failure
When iov_iter_extract_pages() is called on a user-backed iterator, it
pins the extracted pages via pin_user_pages_fast(). If the subsequent
sendpage_ok() check fails, both tls_sw_sendmsg_splice() and
tls_push_data() (device offload path) call iov_iter_revert() to unwind
the iterator position, but iov_iter_revert() only adjusts the cursor -
it does not release the page pin taken by the extract.
> diff --git a/net/tls/tls_device.c b/net/tls/tls_device.c
> index 99c8eff9783e..77922e72c685 100644
> --- a/net/tls/tls_device.c
> +++ b/net/tls/tls_device.c
> @@ -508,6 +508,8 @@ static int tls_push_data(struct sock *sk,
> copy = rc;
>
> if (WARN_ON_ONCE(!sendpage_ok(zc_pfrag.page))) {
> + if (iov_iter_extract_will_pin(iter))
> + unpin_user_page(zc_pfrag.page);
Is this error path reachable for user-backed iterators?
sendpage_ok() only returns false for slab pages or pages with zero refcount.
User pages extracted via pin_user_pages_fast() will always have a positive
refcount and are never slab pages.
Additionally, does this code leak the page pin on the success path?
On success, the extracted page is passed to tls_append_frag(), which acquires
an additional standard page reference via get_page(). The original FOLL_PIN
reference (which includes GUP_PIN_COUNTING_BIAS) is never released by TLS.
When the packet is eventually transmitted and freed, the network stack calls
standard put_page() (via __skb_frag_unref()), which drops only the standard
reference. The pin bias is never cleared, causing a permanent memory leak on
every successful extraction.
If the intent is to support user-backed iterators in MSG_SPLICE_PAGES paths,
this same unpin omission appears to exist in the core MSG_SPLICE_PAGES helper
skb_splice_from_iter() as well.
> iov_iter_revert(iter, copy);
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260429222944.2139041-1-kuba@kernel.org?part=3
next prev parent reply other threads:[~2026-04-30 22:31 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-29 22:29 [PATCH net 0/7] net: tls: fix a few random bugs Jakub Kicinski
2026-04-29 22:29 ` [PATCH net 1/7] net: tls: fix silent data drop under pipe back-pressure Jakub Kicinski
2026-04-29 22:29 ` [PATCH net 2/7] selftests: tls: add test for data loss on small pipe Jakub Kicinski
2026-04-30 22:31 ` sashiko-bot
2026-04-29 22:29 ` [PATCH net 3/7] net: tls: fix page pin leak on sendpage_ok() failure Jakub Kicinski
2026-04-30 22:31 ` sashiko-bot [this message]
2026-04-29 22:29 ` [PATCH net 4/7] net: tls: fix off-by-one in sg_chain entry count for wrapped sk_msg ring Jakub Kicinski
2026-04-30 22:31 ` sashiko-bot
2026-05-01 16:40 ` Sabrina Dubroca
2026-05-03 1:26 ` Jakub Kicinski
2026-04-29 22:29 ` [PATCH net 5/7] selftests: bpf: cover wrapped sk_msg ring chaining in ktls TX path Jakub Kicinski
2026-04-30 17:58 ` Jiayuan Chen
2026-04-30 22:31 ` sashiko-bot
2026-04-29 22:29 ` [PATCH net 6/7] net: tls: fix use-after-free in tls_sw_sendmsg_locked after bpf verdict Jakub Kicinski
2026-04-30 17:50 ` Jiayuan Chen
2026-04-30 22:31 ` sashiko-bot
2026-04-29 22:29 ` [PATCH net 7/7] selftests: bpf: cover tls_sw_sendmsg UAF after bpf_exec_tx_verdict split Jakub Kicinski
2026-04-30 17:55 ` Jiayuan Chen
2026-05-03 2:20 ` [PATCH net 0/7] net: tls: fix a few random bugs patchwork-bot+netdevbpf
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=20260430223131.33668C2BCB3@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=kuba@kernel.org \
--cc=sashiko@lists.linux.dev \
/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.