Re: [PATCH] tipc: fix a potential deadlock on &tx->lock

[Simon Horman]

On Wed, Sep 27, 2023 at 06:14:14PM +0000, Chengfeng Ye wrote:
> It seems that tipc_crypto_key_revoke() could be be invoked by
> wokequeue tipc_crypto_work_rx() under process context and
> timer/rx callback under softirq context, thus the lock acquisition
> on &tx->lock seems better use spin_lock_bh() to prevent possible
> deadlock.
> 
> This flaw was found by an experimental static analysis tool I am
> developing for irq-related deadlock.
> 
> tipc_crypto_work_rx() <workqueue>
> --> tipc_crypto_key_distr()
> --> tipc_bcast_xmit()
> --> tipc_bcbase_xmit()
> --> tipc_bearer_bc_xmit()
> --> tipc_crypto_xmit()
> --> tipc_ehdr_build()
> --> tipc_crypto_key_revoke()
> --> spin_lock(&tx->lock)
> <timer interrupt>
>    --> tipc_disc_timeout()
>    --> tipc_bearer_xmit_skb()
>    --> tipc_crypto_xmit()
>    --> tipc_ehdr_build()
>    --> tipc_crypto_key_revoke()
>    --> spin_lock(&tx->lock) <deadlock here>
> 
> Signed-off-by: Chengfeng Ye <dg573847474@xxxxxxxxx>


Hi Chengfeng Ye,

thanks for your patch.

As a fix for Networking this should probably be targeted at the
'net' tree. Which should be denoted in the subject.

        Subject: [PATCH net] ...

And as a fix this patch should probably have a Fixes tag.
This ones seem appropriate to me, but I could be wrong.

Fixes: fc1b6d6de220 ("tipc: introduce TIPC encryption & authentication")

I don't think it is necessary to repost just to address these issues,
but the Networking maintainers may think otherwise.

The code change itself looks good to me.