mbox series

[net,0/2] Fix use-after-free after the TLS device goes down and up

Message ID 20210524121220.1577321-1-maximmi@nvidia.com
Headers show
Series Fix use-after-free after the TLS device goes down and up | expand

Message

Maxim Mikityanskiy May 24, 2021, 12:12 p.m. UTC
This small series fixes a use-after-free bug in the TLS offload code.
The first patch is a preparation for the second one, and the second is
the fix itself.

Maxim Mikityanskiy (2):
  net/tls: Replace TLS_RX_SYNC_RUNNING with RCU
  net/tls: Fix use-after-free after the TLS device goes down and up

 include/net/tls.h             | 10 +++++-
 net/tls/tls_device.c          | 60 ++++++++++++++++++++++++++++-------
 net/tls/tls_device_fallback.c |  8 +++++
 net/tls/tls_main.c            |  1 +
 4 files changed, 67 insertions(+), 12 deletions(-)

Comments

Jakub Kicinski May 24, 2021, 4:05 p.m. UTC | #1
On Mon, 24 May 2021 15:12:19 +0300 Maxim Mikityanskiy wrote:
> RCU synchronization is guaranteed to finish in finite time, unlike a
> busy loop that polls a flag. This patch is a preparation for the bugfix
> in the next patch, where the same synchronize_net() call will also be
> used to sync with the TX datapath.
> 
> Signed-off-by: Maxim Mikityanskiy <maximmi@nvidia.com>
> Reviewed-by: Tariq Toukan <tariqt@nvidia.com>
> ---
>  include/net/tls.h    |  1 -
>  net/tls/tls_device.c | 10 +++-------
>  2 files changed, 3 insertions(+), 8 deletions(-)
> 
> diff --git a/include/net/tls.h b/include/net/tls.h
> index 3eccb525e8f7..6531ace2a68b 100644
> --- a/include/net/tls.h
> +++ b/include/net/tls.h
> @@ -193,7 +193,6 @@ struct tls_offload_context_tx {
>  	(sizeof(struct tls_offload_context_tx) + TLS_DRIVER_STATE_SIZE_TX)
>  
>  enum tls_context_flags {
> -	TLS_RX_SYNC_RUNNING = 0,
>  	/* Unlike RX where resync is driven entirely by the core in TX only
>  	 * the driver knows when things went out of sync, so we need the flag
>  	 * to be atomic.
> diff --git a/net/tls/tls_device.c b/net/tls/tls_device.c
> index 76a6f8c2eec4..171752cd6910 100644
> --- a/net/tls/tls_device.c
> +++ b/net/tls/tls_device.c
> @@ -680,15 +680,13 @@ static void tls_device_resync_rx(struct tls_context *tls_ctx,
>  	struct tls_offload_context_rx *rx_ctx = tls_offload_ctx_rx(tls_ctx);
>  	struct net_device *netdev;
>  
> -	if (WARN_ON(test_and_set_bit(TLS_RX_SYNC_RUNNING, &tls_ctx->flags)))
> -		return;
> -
>  	trace_tls_device_rx_resync_send(sk, seq, rcd_sn, rx_ctx->resync_type);
> +	rcu_read_lock();
>  	netdev = READ_ONCE(tls_ctx->netdev);
>  	if (netdev)
>  		netdev->tlsdev_ops->tls_dev_resync(netdev, sk, seq, rcd_sn,
>  						   TLS_OFFLOAD_CTX_DIR_RX);

Now this can't sleep right? No bueno.

> -	clear_bit_unlock(TLS_RX_SYNC_RUNNING, &tls_ctx->flags);
> +	rcu_read_unlock();
>  	TLS_INC_STATS(sock_net(sk), LINUX_MIB_TLSRXDEVICERESYNC);
>  }
>
Maxim Mikityanskiy May 25, 2021, 8:52 a.m. UTC | #2
On 2021-05-24 19:05, Jakub Kicinski wrote:
> On Mon, 24 May 2021 15:12:19 +0300 Maxim Mikityanskiy wrote:

>> RCU synchronization is guaranteed to finish in finite time, unlike a

>> busy loop that polls a flag. This patch is a preparation for the bugfix

>> in the next patch, where the same synchronize_net() call will also be

>> used to sync with the TX datapath.

>>

>> Signed-off-by: Maxim Mikityanskiy <maximmi@nvidia.com>

>> Reviewed-by: Tariq Toukan <tariqt@nvidia.com>

>> ---

>>   include/net/tls.h    |  1 -

>>   net/tls/tls_device.c | 10 +++-------

>>   2 files changed, 3 insertions(+), 8 deletions(-)

>>

>> diff --git a/include/net/tls.h b/include/net/tls.h

>> index 3eccb525e8f7..6531ace2a68b 100644

>> --- a/include/net/tls.h

>> +++ b/include/net/tls.h

>> @@ -193,7 +193,6 @@ struct tls_offload_context_tx {

>>   	(sizeof(struct tls_offload_context_tx) + TLS_DRIVER_STATE_SIZE_TX)

>>   

>>   enum tls_context_flags {

>> -	TLS_RX_SYNC_RUNNING = 0,

>>   	/* Unlike RX where resync is driven entirely by the core in TX only

>>   	 * the driver knows when things went out of sync, so we need the flag

>>   	 * to be atomic.

>> diff --git a/net/tls/tls_device.c b/net/tls/tls_device.c

>> index 76a6f8c2eec4..171752cd6910 100644

>> --- a/net/tls/tls_device.c

>> +++ b/net/tls/tls_device.c

>> @@ -680,15 +680,13 @@ static void tls_device_resync_rx(struct tls_context *tls_ctx,

>>   	struct tls_offload_context_rx *rx_ctx = tls_offload_ctx_rx(tls_ctx);

>>   	struct net_device *netdev;

>>   

>> -	if (WARN_ON(test_and_set_bit(TLS_RX_SYNC_RUNNING, &tls_ctx->flags)))

>> -		return;

>> -

>>   	trace_tls_device_rx_resync_send(sk, seq, rcd_sn, rx_ctx->resync_type);

>> +	rcu_read_lock();

>>   	netdev = READ_ONCE(tls_ctx->netdev);

>>   	if (netdev)

>>   		netdev->tlsdev_ops->tls_dev_resync(netdev, sk, seq, rcd_sn,

>>   						   TLS_OFFLOAD_CTX_DIR_RX);

> 

> Now this can't sleep right? No bueno.


No, it can't sleep under RCU. However, are you sure it was allowed to 
sleep before my change? I don't think so. Your commit e52972c11d6b 
("net/tls: replace the sleeping lock around RX resync with a bit lock") 
mentions that "RX resync may get called from soft IRQ", which 
essentially means that it can't sleep.

Furthermore, no implementations try to sleep in RX resync, as far as I 
see from reviewing the code. For example, nfp_net_tls_resync uses 
GFP_ATOMIC for RX resync and GFP_KERNEL for TX resync. 
mlx5_fpga_tls_resync_rx also uses GFP_ATOMIC.

So, I don't think I'm breaking anything with my change.

> 

>> -	clear_bit_unlock(TLS_RX_SYNC_RUNNING, &tls_ctx->flags);

>> +	rcu_read_unlock();

>>   	TLS_INC_STATS(sock_net(sk), LINUX_MIB_TLSRXDEVICERESYNC);

>>   }

>>   

>
Jakub Kicinski May 25, 2021, 5:14 p.m. UTC | #3
On Tue, 25 May 2021 11:52:20 +0300 Maxim Mikityanskiy wrote:
> On 2021-05-24 19:05, Jakub Kicinski wrote:

> > On Mon, 24 May 2021 15:12:19 +0300 Maxim Mikityanskiy wrote:  

> >> RCU synchronization is guaranteed to finish in finite time, unlike a

> >> busy loop that polls a flag. This patch is a preparation for the bugfix

> >> in the next patch, where the same synchronize_net() call will also be

> >> used to sync with the TX datapath.

> >>

> >> Signed-off-by: Maxim Mikityanskiy <maximmi@nvidia.com>

> >> Reviewed-by: Tariq Toukan <tariqt@nvidia.com>

> >> ---

> >>   include/net/tls.h    |  1 -

> >>   net/tls/tls_device.c | 10 +++-------

> >>   2 files changed, 3 insertions(+), 8 deletions(-)

> >>

> >> diff --git a/include/net/tls.h b/include/net/tls.h

> >> index 3eccb525e8f7..6531ace2a68b 100644

> >> --- a/include/net/tls.h

> >> +++ b/include/net/tls.h

> >> @@ -193,7 +193,6 @@ struct tls_offload_context_tx {

> >>   	(sizeof(struct tls_offload_context_tx) + TLS_DRIVER_STATE_SIZE_TX)

> >>   

> >>   enum tls_context_flags {

> >> -	TLS_RX_SYNC_RUNNING = 0,

> >>   	/* Unlike RX where resync is driven entirely by the core in TX only

> >>   	 * the driver knows when things went out of sync, so we need the flag

> >>   	 * to be atomic.

> >> diff --git a/net/tls/tls_device.c b/net/tls/tls_device.c

> >> index 76a6f8c2eec4..171752cd6910 100644

> >> --- a/net/tls/tls_device.c

> >> +++ b/net/tls/tls_device.c

> >> @@ -680,15 +680,13 @@ static void tls_device_resync_rx(struct tls_context *tls_ctx,

> >>   	struct tls_offload_context_rx *rx_ctx = tls_offload_ctx_rx(tls_ctx);

> >>   	struct net_device *netdev;

> >>   

> >> -	if (WARN_ON(test_and_set_bit(TLS_RX_SYNC_RUNNING, &tls_ctx->flags)))

> >> -		return;

> >> -

> >>   	trace_tls_device_rx_resync_send(sk, seq, rcd_sn, rx_ctx->resync_type);

> >> +	rcu_read_lock();

> >>   	netdev = READ_ONCE(tls_ctx->netdev);

> >>   	if (netdev)

> >>   		netdev->tlsdev_ops->tls_dev_resync(netdev, sk, seq, rcd_sn,

> >>   						   TLS_OFFLOAD_CTX_DIR_RX);  

> > 

> > Now this can't sleep right? No bueno.  

> 

> No, it can't sleep under RCU. However, are you sure it was allowed to 

> sleep before my change? I don't think so. Your commit e52972c11d6b 

> ("net/tls: replace the sleeping lock around RX resync with a bit lock") 

> mentions that "RX resync may get called from soft IRQ", which 

> essentially means that it can't sleep.

> 

> Furthermore, no implementations try to sleep in RX resync, as far as I 

> see from reviewing the code. For example, nfp_net_tls_resync uses 

> GFP_ATOMIC for RX resync and GFP_KERNEL for TX resync. 

> mlx5_fpga_tls_resync_rx also uses GFP_ATOMIC.

> 

> So, I don't think I'm breaking anything with my change.


You're right.