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 PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Thu, 14 Apr 2022 12:28:08 +0200 From: Jakub Kicinski <kuba@...nel.org> To: Maxim Mikityanskiy <maximmi@...dia.com> Cc: Boris Pismenny <borisp@...dia.com>, John Fastabend <john.fastabend@...il.com>, Daniel Borkmann <daniel@...earbox.net>, "David S. Miller" <davem@...emloft.net>, Paolo Abeni <pabeni@...hat.com>, Tariq Toukan <tariqt@...dia.com>, Aviad Yehezkel <aviadye@...lanox.com>, "Ilya Lesokhin" <ilyal@...lanox.com>, <netdev@...r.kernel.org> Subject: Re: [PATCH net] tls: Skip tls_append_frag on zero copy size On Wed, 13 Apr 2022 16:49:56 +0300 Maxim Mikityanskiy wrote: > Calling tls_append_frag when max_open_record_len == record->len might > add an empty fragment to the TLS record if the call happens to be on the > page boundary. Normally tls_append_frag coalesces the zero-sized > fragment to the previous one, but not if it's on page boundary. > > If a resync happens then, the mlx5 driver posts dump WQEs in > tx_post_resync_dump, and the empty fragment may become a data segment > with byte_count == 0, which will confuse the NIC and lead to a CQE > error. > > This commit fixes the described issue by skipping tls_append_frag on > zero size to avoid adding empty fragments. The fix is not in the driver, > because an empty fragment is hardly the desired behavior. > > Fixes: e8f69799810c ("net/tls: Add generic NIC offload infrastructure") > Signed-off-by: Maxim Mikityanskiy <maximmi@...dia.com> > Reviewed-by: Tariq Toukan <tariqt@...dia.com> > --- > net/tls/tls_device.c | 12 +++++++----- > 1 file changed, 7 insertions(+), 5 deletions(-) > > diff --git a/net/tls/tls_device.c b/net/tls/tls_device.c > index 12f7b56771d9..af875ad4a822 100644 > --- a/net/tls/tls_device.c > +++ b/net/tls/tls_device.c > @@ -483,11 +483,13 @@ static int tls_push_data(struct sock *sk, > copy = min_t(size_t, size, (pfrag->size - pfrag->offset)); > copy = min_t(size_t, copy, (max_open_record_len - record->len)); > > - rc = tls_device_copy_data(page_address(pfrag->page) + > - pfrag->offset, copy, msg_iter); > - if (rc) > - goto handle_error; > - tls_append_frag(record, pfrag, copy); > + if (copy) { > + rc = tls_device_copy_data(page_address(pfrag->page) + > + pfrag->offset, copy, msg_iter); > + if (rc) > + goto handle_error; > + tls_append_frag(record, pfrag, copy); > + } I appreciate you're likely trying to keep the fix minimal but Greg always says "fix it right, worry about backports later". I think we should skip more, we can reorder the mins and if min(size, rec space) == 0 then we can skip the allocation as well. Maybe some application wants to do zero-length sends to flush the MSG_MORE and would benefit that way? > size -= copy; > if (!size) {
Powered by blists - more mailing lists