summaryrefslogtreecommitdiff
path: root/net/tipc/crypto.c
diff options
context:
space:
mode:
authorTuong Lien <tuong.t.lien@dektech.com.au>2020-06-02 11:46:40 +0700
committerDavid S. Miller <davem@davemloft.net>2020-06-02 15:13:46 -0700
commit049fa17f7ae6b0971ad41b761479962facafea4b (patch)
tree7fca7334b7c3d61af4558afda17c449768673240 /net/tipc/crypto.c
parent11e877b2a8cfd282a1b81f9d4c594b900889a5d8 (diff)
Revert "tipc: Fix potential tipc_node refcnt leak in tipc_rcv"
This reverts commit de058420767df21e2b6b0f3bb36d1616fb962032. There is no actual tipc_node refcnt leak as stated in the above commit. The refcnt is hold carefully for the case of an asynchronous decryption (i.e. -EINPROGRESS/-EBUSY and skb = NULL is returned), so that the node object cannot be freed in the meantime. The counter will be re-balanced when the operation's callback arrives with the decrypted buffer if any. In other cases, e.g. a synchronous crypto the counter will be decreased immediately when it is done. Now with that commit, a kernel panic will occur when there is no node found (i.e. n = NULL) in the 'tipc_rcv()' or a premature release of the node object. This commit solves the issues by reverting the said commit, but keeping one valid case that the 'skb_linearize()' is failed. Acked-by: Jon Maloy <jmaloy@redhat.com> Signed-off-by: Tuong Lien <tuong.t.lien@dektech.com.au> Tested-by: Hoang Le <hoang.h.le@dektech.com.au> Signed-off-by: David S. Miller <davem@davemloft.net>
Diffstat (limited to 'net/tipc/crypto.c')
0 files changed, 0 insertions, 0 deletions