netdev - [RFC net] net/tls: clear SG markings on encryption error

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-Id: <20191122214553.20982-1-jakub.kicinski@netronome.com>
Date:   Fri, 22 Nov 2019 13:45:53 -0800
From:   Jakub Kicinski <jakub.kicinski@...ronome.com>
To:     borisp@...lanox.com, aviadye@...lanox.com,
        john.fastabend@...il.com, daniel@...earbox.net
Cc:     netdev@...r.kernel.org,
        Jakub Kicinski <jakub.kicinski@...ronome.com>,
        syzbot+df0d4ec12332661dd1f9@...kaller.appspotmail.com
Subject: [RFC net] net/tls: clear SG markings on encryption error

When tls_do_encryption() fails the SG lists are left with the
SG_END and SG_CHAIN marks in place. One could hope that once
encryption fails we will never see the record again, but that
is in fact not true. Commit d3b18ad31f93 ("tls: add bpf support
to sk_msg handling") added special handling to ENOMEM and ENOSPC
errors which mean we may see the same record re-submitted.

In all honesty I don't understand why we need the ENOMEM handling.
Waiting for socket memory without setting SOCK_NOSPACE on any
random memory allocation failure seems slightly ill advised.

Having said that, undoing the SG markings seems wise regardless.

Reported-by: syzbot+df0d4ec12332661dd1f9@...kaller.appspotmail.com
Fixes: 130b392c6cd6 ("net: tls: Add tls 1.3 support")
Fixes: d3b18ad31f93 ("tls: add bpf support to sk_msg handling")
Signed-off-by: Jakub Kicinski <jakub.kicinski@...ronome.com>
---
John, I'm sending this mostly to ask if we can safely remove
the ENOMEM handling? :)

I was going to try the sockmap tests myself, but looks like the current
LLVM 10 build I get from their debs just segfaults when trying to build
selftest :/

Also there's at least one more bug in this piece of code, TLS 1.3
can't assume there's at least one free SG entry.

 net/tls/tls_sw.c | 13 +++++++++++++
 1 file changed, 13 insertions(+)

diff --git a/net/tls/tls_sw.c b/net/tls/tls_sw.c
index 24161750a737..4a0ea87b20cf 100644
--- a/net/tls/tls_sw.c
+++ b/net/tls/tls_sw.c
@@ -737,6 +737,19 @@ static int tls_push_record(struct sock *sk, int flags,
 	if (rc < 0) {
 		if (rc != -EINPROGRESS) {
 			tls_err_abort(sk, EBADMSG);
+
+			i = msg_pl->sg.end;
+			if (prot->version == TLS_1_3_VERSION) {
+				sg_mark_end(sk_msg_elem(msg_pl, i));
+				sg_unmark_end(sk_msg_elem(msg_pl, i));
+			}
+			sk_msg_iter_var_prev(i);
+			sg_unmark_end(sk_msg_elem(msg_pl, i));
+
+			i = msg_en->sg.end;
+			sk_msg_iter_var_prev(i);
+			sg_unmark_end(sk_msg_elem(msg_en, i));
+
 			if (split) {
 				tls_ctx->pending_open_record_frags = true;
 				tls_merge_open_record(sk, rec, tmp, orig_end);
-- 
2.23.0