After tls_set_device_offload() fails, we enter tls_set_sw_offload(). But
tls_set_sw_offload can't set cctx->iv and cctx->rec_seq to NULL if it fails
before kmalloc cctx->iv. It is better to Set them to NULL to avoid any
potential info leak.
Fixes: e8f69799810c ("net/tls: Add generic NIC offload infrastructure")
Signed-off-by: Hangyu Hua <[email protected]>
---
v2: change commit log. The original issue will be fixed in another patch.
net/tls/tls_device.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/net/tls/tls_device.c b/net/tls/tls_device.c
index 6c593788dc25..a63f6f727f58 100644
--- a/net/tls/tls_device.c
+++ b/net/tls/tls_device.c
@@ -1241,8 +1241,10 @@ int tls_set_device_offload(struct sock *sk, struct tls_context *ctx)
kfree(start_marker_record);
free_rec_seq:
kfree(ctx->tx.rec_seq);
+ ctx->tx.rec_seq = NULL;
free_iv:
kfree(ctx->tx.iv);
+ ctx->tx.iv = NULL;
release_netdev:
dev_put(netdev);
return rc;
--
2.34.1
On Fri, 24 Feb 2023 18:28:39 +0800 Hangyu Hua wrote:
> After tls_set_device_offload() fails, we enter tls_set_sw_offload(). But
> tls_set_sw_offload can't set cctx->iv and cctx->rec_seq to NULL if it fails
> before kmalloc cctx->iv. It is better to Set them to NULL to avoid any
> potential info leak.
Please show clear chain of events which can lead to a use-after-free
or info leak. And if you can't please don't send the patch.
2023-02-24, 10:57:29 -0800, Jakub Kicinski wrote:
> On Fri, 24 Feb 2023 18:28:39 +0800 Hangyu Hua wrote:
> > After tls_set_device_offload() fails, we enter tls_set_sw_offload(). But
> > tls_set_sw_offload can't set cctx->iv and cctx->rec_seq to NULL if it fails
> > before kmalloc cctx->iv. It is better to Set them to NULL to avoid any
> > potential info leak.
>
> Please show clear chain of events which can lead to a use-after-free
> or info leak. And if you can't please don't send the patch.
Sorry, I thought in this morning's discussion Hangyu had agreed to
remove all mentions of possible info leak while sending v2, since we
agreed [1] that this patch didn't fix any issue, just that it looked
more consistent, as tls_set_sw_offload NULLs iv and rec_seq on
failure. We can also drop the patch completely. Anyway since net-next
is closed, I should have told Hangyu to wait for 2 weeks.
[1] https://lore.kernel.org/all/[email protected]/
--
Sabrina
On 25/2/2023 04:22, Sabrina Dubroca wrote:
> 2023-02-24, 10:57:29 -0800, Jakub Kicinski wrote:
>> On Fri, 24 Feb 2023 18:28:39 +0800 Hangyu Hua wrote:
>>> After tls_set_device_offload() fails, we enter tls_set_sw_offload(). But
>>> tls_set_sw_offload can't set cctx->iv and cctx->rec_seq to NULL if it fails
>>> before kmalloc cctx->iv. It is better to Set them to NULL to avoid any
>>> potential info leak.
>>
>> Please show clear chain of events which can lead to a use-after-free
>> or info leak. And if you can't please don't send the patch.
>
> Sorry, I thought in this morning's discussion Hangyu had agreed to
> remove all mentions of possible info leak while sending v2, since we
> agreed [1] that this patch didn't fix any issue, just that it looked
> more consistent, as tls_set_sw_offload NULLs iv and rec_seq on
> failure. We can also drop the patch completely. Anyway since net-next
> is closed, I should have told Hangyu to wait for 2 weeks.
>
> [1] https://lore.kernel.org/all/[email protected]/
>
Oops. I will make a whole new patch without mentions of info leak in a
few weeks. Please ignore this patch.