From: John Fastabend <john.fastabend@gmail.com>
To: netdev@vger.kernel.org, eadavis@qq.com, kuba@kernel.org
Cc: john.fastabend@gmail.com, bpf@vger.kernel.org, borisp@nvidia.com
Subject: [PATCH net 1/2] net: tls, fix WARNIING in __sk_msg_free
Date: Wed, 10 Jan 2024 14:01:23 -0800 [thread overview]
Message-ID: <20240110220124.452746-2-john.fastabend@gmail.com> (raw)
In-Reply-To: <20240110220124.452746-1-john.fastabend@gmail.com>
A splice with MSG_SPLICE_PAGES will cause tls code to use the
tls_sw_sendmsg_splice path in the TLS sendmsg code to move the user
provided pages from the msg into the msg_pl. This will loop over the
msg until msg_pl is full, checked by sk_msg_full(msg_pl). The user
can also set the MORE flag to hint stack to delay sending until receiving
more pages and ideally a full buffer.
If the user adds more pages to the msg than can fit in the msg_pl
scatterlist (MAX_MSG_FRAGS) we should ignore the MORE flag and send
the buffer anyways.
What actually happens though is we abort the msg to msg_pl scatterlist
setup and then because we forget to set 'full record' indicating we
can no longer consume data without a send we fallthrough to the 'continue'
path which will check if msg_data_left(msg) has more bytes to send and
then attempts to fit them in the already full msg_pl. Then next
iteration of sender doing send will encounter a full msg_pl and throw
the warning in the syzbot report.
To fix simply check if we have a full_record in splice code path and
if not send the msg regardless of MORE flag.
Reported-and-tested-by: syzbot+f2977222e0e95cec15c8@syzkaller.appspotmail.com
Reported-by: Edward Adam Davis <eadavis@qq.com>
Fixes: fe1e81d4f73b ("tls/sw: Support MSG_SPLICE_PAGES")
Signed-off-by: John Fastabend <john.fastabend@gmail.com>
---
net/tls/tls_sw.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/net/tls/tls_sw.c b/net/tls/tls_sw.c
index e37b4d2e2acd..31e8a94dfc11 100644
--- a/net/tls/tls_sw.c
+++ b/net/tls/tls_sw.c
@@ -1052,7 +1052,11 @@ static int tls_sw_sendmsg_locked(struct sock *sk, struct msghdr *msg,
if (ret < 0)
goto send_end;
tls_ctx->pending_open_record_frags = true;
- if (full_record || eor || sk_msg_full(msg_pl))
+
+ if (sk_msg_full(msg_pl))
+ full_record = true;
+
+ if (full_record || eor)
goto copied;
continue;
}
--
2.33.0
next prev parent reply other threads:[~2024-01-10 22:01 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-10 22:01 [PATCH net 0/2] tls fixes for SPLICE with more hint John Fastabend
2024-01-10 22:01 ` John Fastabend [this message]
2024-01-12 1:05 ` [PATCH net 1/2] net: tls, fix WARNIING in __sk_msg_free Jakub Kicinski
2024-01-10 22:01 ` [PATCH net 2/2] net: tls, add test to capture error on large splice John Fastabend
2024-01-12 1:05 ` Jakub Kicinski
2024-01-12 21:52 ` John Fastabend
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=20240110220124.452746-2-john.fastabend@gmail.com \
--to=john.fastabend@gmail.com \
--cc=borisp@nvidia.com \
--cc=bpf@vger.kernel.org \
--cc=eadavis@qq.com \
--cc=kuba@kernel.org \
--cc=netdev@vger.kernel.org \
/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.