[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <9a4d11c7-390a-519f-ef04-d5de55b27f29@gmail.com>
Date: Mon, 27 Feb 2023 13:53:43 +0800
From: Hangyu Hua <hbh25y@...il.com>
To: Sabrina Dubroca <sd@...asysnail.net>,
Jakub Kicinski <kuba@...nel.org>
Cc: borisp@...dia.com, john.fastabend@...il.com, davem@...emloft.net,
edumazet@...gle.com, pabeni@...hat.com, ilyal@...lanox.com,
aviadye@...lanox.com, netdev@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2] net: tls: fix possible info leak in
tls_set_device_offload()
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/310391ea-7c71-395e-5dcb-b0a983e6fc93@gmail.com/
>
Oops. I will make a whole new patch without mentions of info leak in a
few weeks. Please ignore this patch.
Powered by blists - more mailing lists